9 ms·

JavaScript is the new Perl

32 points by ct 14y ago

jfb 14y ago
I don't think that people's problems with perl < 5.0 was it's lack of "object oriented" features. Perl's object system is quite interesting, but orthogonal to the perceived ickiness of perl the language.
staticsafe 14y ago
Site seems to be timing out here.
- coroxout 14y ago
  Same here. No-image Google cache version here: http://webcache.googleusercontent.com/search?q=cache:QFxSoJi4FgkJ:ocpsoft.org/opensource/javascript-is-the-new-perl/&strip=1 http://webcache.googleusercontent.com/search?q=cache:QFxSoJi...
- lincolnbaxter 14y ago
  Should be better now.
noonespecial 14y ago
I think part of the problem with JavaScript, php, perl, etc is that is there, by default, everywhere. A great many beginners do some very ugly things with it because it's already on the system they have and there's tons of not so good examples on the Internet to cut and paste. I'd bet there are plenty of people creating web sites who aren't entirely clear on where HTML stops and JavaScript starts. Ruby, for example not only has to be installed on most older systems, you'd have to know that you wanted ruby in the first place. This alone acts as a giant filter. Anyone who knows they want to use ruby is already going to produce better code. Edit: Please s/ruby//g with anything slightly more obscure than perl/php like python, go, object-pascal, etc. I'm not trying to be a ruby elitist here. It was just an example.
- Falling3 14y ago
  That doesn't sound elitist at all...
  - noonespecial 14y ago
    I don't mean it too. I produced the most awful, unreadable, barely functional drek you can imagine for far longer than I should have as a beginner with perl. The point is, that it might not be a failing of perl and JavaScript that makes so much code written in it so ugly. Its accessibility might actually be a good thing, with this simple side effect.
- beebs93 14y ago
  They are not "already" going to produce better code. I have nothing against Ruby, but its devs are not endowed with better programming practices. I do agree with you that it acts as a filter of sorts, but only for now. Anything that is not mainstream tends to act this way.
- adamors 14y ago
  PHP is most likely not on the system they have. I don't know about OS X but it doesn't come with any popular Linux distro and it doesn't come with Windows either. Neither does Perl.
  - noonespecial 14y ago
    Most people don't try to host their first web site on their windows box. They likely get a shared host for $3 a month somewhere. This probably has a little sample site with a few lines of PHP and some JavaScript on it. When I started, I did not know the difference between PHP, JavaScript and HTML. I thought it was all "web markup".
    - adamors 14y ago
      > Most people don't try to host their first web site on their windows box. Most people dont host their first web site period. I never heard of anyone who didn't learn PHP offline, on a local Apache server.
trimbo 14y ago
Is he trying to say that everything we write today in Javascript will probably be rewritten like everything we wrote in Perl in the 90s got rewritten? That's probably true, but it doesn't mean "Javascript is the new Perl" Perl had zero corporate investment from a application development perspective. Java had an enormous amount -- and still does. Now take a look at Javascript. Javascript is the first language since Java to have gotten this much investment across a lot of enterprises. Google, Microsoft, of course, but also the rise of startups like Meteor. For Javascript to go away the way Perl did for app development will require too much retooling.
smosher 14y ago
Perl was never as popular as JavaScript has become lately, I don't know what to say. Spoiler: apparently ES6 is going to kill ES5. Personally I'm shocked.
- evincarofautumn 14y ago
  If you replace “popular” with “visible”, then it makes a kind of sense.
kalms 14y ago
Seems like a weird comparison. JavaScript is obligatory and available in all common browsers. It's fairly easy to get started, and even easier to actually accomplish something with it. Not sure if Perl is as accommodating (haven't tried it though). When all is said and done JavaScript is a very popular language. When you leave a company, having build something fairly complex - If you did your job properly, documented your code and followed common sense, the project will probably live on. The author also speaks off everyone hating Perl. Is JavaScript really as hated? I don't get that impression at all.
- evincarofautumn 14y ago
  Lover of Perl and JavaScript alike here. It is a weird comparison. The two languages are used in very different ways; I guess the author is saying JavaScript will be supplanted by something nicer, like Perl has been. But Perl hasn’t been. Python and Ruby are cohabitors, not usurpers. A sizable chunk of the web’s infrastructure is still Perl, and that is unlikely to change. To give you an idea of the language, Perl is very easy to use, and very hard to grok. The language is large and complex, but most of the size and complexity have to do with being as helpful to the programmer as possible. If you use things in a way that seems plausible, your expectations probably won’t be violated. But if you want to deeply understand how something works, be prepared to discover many details you didn’t expect about how the language is silently helping you out. It’s a relatively painless experience, even if you don’t know a lot of Perl, to glue a few CPAN modules together and get something working. In that respect it’s similar to writing a Node.js application, though the set of Node libraries is, last I knew, laughably small by comparison. Having maintained both large-scale JavaScript and Perl codebases, I can tell you that it’s much easier to deal with Perl. Having a proper module system is a huge boon, as well as sane handling of types, and some compile-time checking. Perl is dynamic, yes, but types are explicit by way of sigils—in Perl 5, essentially typed dereferencing operators. The main difficulty in Perl is the same as in any dynamic language: refactoring. It can be a pain to change things, because many of the resulting errors are not checked till runtime. A comprehensive test suite helps with this; Perl’s testing culture is very good, and comparable to that of Ruby. JavaScript developers tend not, in my experience, to write tests. So not everybody hates Perl, and not everybody hates JavaScript. People who’ve actually used a language tend not to hate it as much as those who haven’t. This article is, in that regard, just plain silly.
ojr 14y ago
If you say Javascript is becoming an assembly language, you never coded in assembly language, it is not "impossible" to maintain a javascript project, if you can get pass that it is not java, people have been doing it for years and will continue to do so in the near future
- sophacles 14y ago
  Building on this point: there are more and more libraries and frameworks in javascript that follow best practices in keeping things modular, well separated and differentiating core-app code from DOM manipulation.
- dotborg 14y ago
  at all costs sure, but why should I waste so much time?
arnorhs 14y ago
I don't really feel like being the next Perl is a bad thing, contrary to the article's premise. However, the author is making a lot of unbacked and sensational claims. I feel inclined to comment on each part. > everyone hates [Perl] because it’s “too hard to maintain” and too “strange.” I didn't know everyone hates Perl and I also didn't know those were the reason. Surely we don't want strange languages? </sarcasm> > global variables in JavaScript have been at the root of nearly every client-side security exploit to date. Where does this information come from? > In the mean time, to work around some of these issues, JavaScript is still being used much like an Assembly language. How is javascript like assembly? > We are seeing a similar explosion of packages (libraries), like Perl did, which led to the development of CPAN (you could akin this to the jQuery plugin ecosystem, which is neither as formal, reliable, nor as convenient or automated.) Also worth mentioning is node's NPM, in which case the above argument is not true. And also, github and great search engines did not exist at the time that CPAN came out, and it's hard to imagine it would have gained the same amount of traction, because it's simply not necessary for the most part. > There’s a similar explosion of JavaScript implementations on server side and in other languages, leading to issues with compatibility and runtime bugs. What is this based on? I haven't seen many problems with compatibility and runtime bugs in the Node ecosystem at all. However I've never used Rhino, and perhaps that's what he's talking about. Does the author have any experience with Node? > Still don’t believe that JavaScript is the new Perl? Compare jQuery to Perl CGI. Nobody actually does plain “JavaScript” programming for the web anymore, not really anyway. Do they use the core language? Yes. But we no longer use any of the built-in JavaScript->HTML functionality directly. Only holds limited truth for browser development. Everybody using jquery is using plain Javascript. They are interfacing with the DOM API through jQuery and using the jQuery library. But the comparison is like saying anybody who uses a 3rd party library in Java is not using the real language. A language is not the API that you're using. > jQuery is the glue that holds together the JavaScript ecosystem, provides browser compatibility, and it admittedly does a pretty good job. what? > however, sooner or later, the lack of language constructs like truly enforceable namespace boundaries, and the general mess created when teams get a little bit bigger is going to set in. Name spacing is easily solved using module loaders and proper scoping. > This is seen over and over as the new wave of developers comes into corporate life: Larger companies try it out, then decide it’s costing measurably, then switch back. It would be interesting to know which large companies have been trying it out and then deciding it's costing them too much money and switching back. > We ARE inherently lazy and most of us will ignore nearly any best practice or principle once “that deadline” gets too close. Sorry, this just means you're a shitty developer and/or can't manage deadlines very well. > Still, you don’t see that many big Python and Ruby shops either (Google is an exception,) His exception is a pretty large one. And besides that, which companies has the author studied? I'm not going to comment on any of the Java claims, since I don't have that much experience with Java. All in all this article is incredibly biased towards Java and affected by large amount of disinformation about Javascript in general.
dotborg 14y ago
There was much more "magic" in CGI/Perl. The only "magic" in JS in fact is caused by browser vendors and have nothing to do with language itself.
FuzzyDunlop 14y ago
> Nobody actually does plain “JavaScript” programming for the web anymore, not really anyway. Do they use the core language? Yes. But we no longer use any of the built-in JavaScript->HTML functionality directly. Which is sort of a shame because there's stuff in there that totally obviates the need to haphazardly traverse the dom with jQuery. Finding the form an input element belongs to in jQuery: $('input').parents('form'); // or probably $('input').parent().parent().parent().find('form'); Finding the same thing using the DOM API: document.querySelector('input').form; You'd want to mix those two, in a real use case: $('input').on('click', function(evt) { var form = this.form; }); Then you don't even need jQuery to use the FormData API: // where `submit` uses XHR2 to make a request <input type="submit" onclick="submit(this.form)">
- Groxx 14y ago
  Unless you want to support IE7, that is. http://caniuse.com/#search=queryselector http://caniuse.com/#search=queryselector Not that I recommend doing so, but in many cases you don't have a choice. Or you started working on a project that originally needed to, and maintaining consistent style might lead you to use jQuery everywhere.
  - FuzzyDunlop 14y ago
    Of course. My main point wasn't the use of querySelector per se, but the ability to access the exact DOM element(s) you need without crazy querying or traversal. While the DOM API isn't perfect by any means, and jQuery fills that gap really well, there are still times where the OOP nature of the DOM gets you exactly what you want with minimal faff. The other problem is the relative obscurity of it thanks to jQuery and crowd-sourced DOM documentation (via MDN).
    - Groxx 14y ago
      yeah, jQuery certainly eclipses everything else. Though I don't know what you mean by obscurity + MDN... it does seem weirdly anaemic for such a big / complex / important piece of the API, but I don't know if I'd call MDN obscure. Or, I hope it isn't, I find it wildly useful.
ctek 14y ago
We have an extensive JavaScript codebase at the large corporation I work at and by simply enforcing the use of ECMAScript 5 Strict Mode and verifying with JSLint we are able to catch most potential issues but then again, nobody there is writing large systems in JavaScript, only flourishes of browser-side interactivity...
- mattacular 14y ago
  I'm hoping Node continues to gain popularity. The idea of using the same language on the serverside and clientside seems too enticing to fail.
jarjoura 14y ago
Point 1: There is no other way to write client-side browser applications. Point 2: Node.js allows a team of 1-2 quickly get a server-side app up and running. Once a project takes off and needs to scale to a larger team, it's extremely easy to switch to and write C++ components. Point 3: Who cares if history is repeating itself or not. It's an impressive technology stack with huge corporate backers. Besides, Perl is still used and although nowhere near as cool, still works great for writing shell scripts.
azakai 14y ago
> a stack that is resilient enough to withstand sloppy code. There is no such magic stack that withstands sloppy code.

32 points by ct 14y ago

jfb 14y ago

I don't think that people's problems with perl < 5.0 was it's lack of "object oriented" features. Perl's object system is quite interesting, but orthogonal to the perceived ickiness of perl the language.

staticsafe 14y ago

Site seems to be timing out here.

coroxout 14y ago
Same here. No-image Google cache version here: http://webcache.googleusercontent.com/search?q=cache:QFxSoJi4FgkJ:ocpsoft.org/opensource/javascript-is-the-new-perl/&strip=1 http://webcache.googleusercontent.com/search?q=cache:QFxSoJi...
lincolnbaxter 14y ago
Should be better now.

noonespecial 14y ago

I think part of the problem with JavaScript, php, perl, etc is that is there, by default, everywhere. A great many beginners do some very ugly things with it because it's already on the system they have and there's tons of not so good examples on the Internet to cut and paste. I'd bet there are plenty of people creating web sites who aren't entirely clear on where HTML stops and JavaScript starts. Ruby, for example not only has to be installed on most older systems, you'd have to know that you wanted ruby in the first place. This alone acts as a giant filter. Anyone who knows they want to use ruby is already going to produce better code. Edit: Please s/ruby//g with anything slightly more obscure than perl/php like python, go, object-pascal, etc. I'm not trying to be a ruby elitist here. It was just an example.

Falling3 14y ago
That doesn't sound elitist at all...
- noonespecial 14y ago
  I don't mean it too. I produced the most awful, unreadable, barely functional drek you can imagine for far longer than I should have as a beginner with perl. The point is, that it might not be a failing of perl and JavaScript that makes so much code written in it so ugly. Its accessibility might actually be a good thing, with this simple side effect.
beebs93 14y ago
They are not "already" going to produce better code. I have nothing against Ruby, but its devs are not endowed with better programming practices. I do agree with you that it acts as a filter of sorts, but only for now. Anything that is not mainstream tends to act this way.
adamors 14y ago
PHP is most likely not on the system they have. I don't know about OS X but it doesn't come with any popular Linux distro and it doesn't come with Windows either. Neither does Perl.
- noonespecial 14y ago
  Most people don't try to host their first web site on their windows box. They likely get a shared host for $3 a month somewhere. This probably has a little sample site with a few lines of PHP and some JavaScript on it. When I started, I did not know the difference between PHP, JavaScript and HTML. I thought it was all "web markup".
  - adamors 14y ago
    > Most people don't try to host their first web site on their windows box. Most people dont host their first web site period. I never heard of anyone who didn't learn PHP offline, on a local Apache server.

trimbo 14y ago

Is he trying to say that everything we write today in Javascript will probably be rewritten like everything we wrote in Perl in the 90s got rewritten? That's probably true, but it doesn't mean "Javascript is the new Perl" Perl had zero corporate investment from a application development perspective. Java had an enormous amount -- and still does. Now take a look at Javascript. Javascript is the first language since Java to have gotten this much investment across a lot of enterprises. Google, Microsoft, of course, but also the rise of startups like Meteor. For Javascript to go away the way Perl did for app development will require too much retooling.

smosher 14y ago

Perl was never as popular as JavaScript has become lately, I don't know what to say. Spoiler: apparently ES6 is going to kill ES5. Personally I'm shocked.

evincarofautumn 14y ago
If you replace “popular” with “visible”, then it makes a kind of sense.

kalms 14y ago

Seems like a weird comparison. JavaScript is obligatory and available in all common browsers. It's fairly easy to get started, and even easier to actually accomplish something with it. Not sure if Perl is as accommodating (haven't tried it though). When all is said and done JavaScript is a very popular language. When you leave a company, having build something fairly complex - If you did your job properly, documented your code and followed common sense, the project will probably live on. The author also speaks off everyone hating Perl. Is JavaScript really as hated? I don't get that impression at all.

evincarofautumn 14y ago
Lover of Perl and JavaScript alike here. It is a weird comparison. The two languages are used in very different ways; I guess the author is saying JavaScript will be supplanted by something nicer, like Perl has been. But Perl hasn’t been. Python and Ruby are cohabitors, not usurpers. A sizable chunk of the web’s infrastructure is still Perl, and that is unlikely to change. To give you an idea of the language, Perl is very easy to use, and very hard to grok. The language is large and complex, but most of the size and complexity have to do with being as helpful to the programmer as possible. If you use things in a way that seems plausible, your expectations probably won’t be violated. But if you want to deeply understand how something works, be prepared to discover many details you didn’t expect about how the language is silently helping you out. It’s a relatively painless experience, even if you don’t know a lot of Perl, to glue a few CPAN modules together and get something working. In that respect it’s similar to writing a Node.js application, though the set of Node libraries is, last I knew, laughably small by comparison. Having maintained both large-scale JavaScript and Perl codebases, I can tell you that it’s much easier to deal with Perl. Having a proper module system is a huge boon, as well as sane handling of types, and some compile-time checking. Perl is dynamic, yes, but types are explicit by way of sigils—in Perl 5, essentially typed dereferencing operators. The main difficulty in Perl is the same as in any dynamic language: refactoring. It can be a pain to change things, because many of the resulting errors are not checked till runtime. A comprehensive test suite helps with this; Perl’s testing culture is very good, and comparable to that of Ruby. JavaScript developers tend not, in my experience, to write tests. So not everybody hates Perl, and not everybody hates JavaScript. People who’ve actually used a language tend not to hate it as much as those who haven’t. This article is, in that regard, just plain silly.

ojr 14y ago

If you say Javascript is becoming an assembly language, you never coded in assembly language, it is not "impossible" to maintain a javascript project, if you can get pass that it is not java, people have been doing it for years and will continue to do so in the near future

sophacles 14y ago
Building on this point: there are more and more libraries and frameworks in javascript that follow best practices in keeping things modular, well separated and differentiating core-app code from DOM manipulation.
dotborg 14y ago
at all costs sure, but why should I waste so much time?

arnorhs 14y ago

I don't really feel like being the next Perl is a bad thing, contrary to the article's premise. However, the author is making a lot of unbacked and sensational claims. I feel inclined to comment on each part. > everyone hates [Perl] because it’s “too hard to maintain” and too “strange.” I didn't know everyone hates Perl and I also didn't know those were the reason. Surely we don't want strange languages? </sarcasm> > global variables in JavaScript have been at the root of nearly every client-side security exploit to date. Where does this information come from? > In the mean time, to work around some of these issues, JavaScript is still being used much like an Assembly language. How is javascript like assembly? > We are seeing a similar explosion of packages (libraries), like Perl did, which led to the development of CPAN (you could akin this to the jQuery plugin ecosystem, which is neither as formal, reliable, nor as convenient or automated.) Also worth mentioning is node's NPM, in which case the above argument is not true. And also, github and great search engines did not exist at the time that CPAN came out, and it's hard to imagine it would have gained the same amount of traction, because it's simply not necessary for the most part. > There’s a similar explosion of JavaScript implementations on server side and in other languages, leading to issues with compatibility and runtime bugs. What is this based on? I haven't seen many problems with compatibility and runtime bugs in the Node ecosystem at all. However I've never used Rhino, and perhaps that's what he's talking about. Does the author have any experience with Node? > Still don’t believe that JavaScript is the new Perl? Compare jQuery to Perl CGI. Nobody actually does plain “JavaScript” programming for the web anymore, not really anyway. Do they use the core language? Yes. But we no longer use any of the built-in JavaScript->HTML functionality directly. Only holds limited truth for browser development. Everybody using jquery is using plain Javascript. They are interfacing with the DOM API through jQuery and using the jQuery library. But the comparison is like saying anybody who uses a 3rd party library in Java is not using the real language. A language is not the API that you're using. > jQuery is the glue that holds together the JavaScript ecosystem, provides browser compatibility, and it admittedly does a pretty good job. what? > however, sooner or later, the lack of language constructs like truly enforceable namespace boundaries, and the general mess created when teams get a little bit bigger is going to set in. Name spacing is easily solved using module loaders and proper scoping. > This is seen over and over as the new wave of developers comes into corporate life: Larger companies try it out, then decide it’s costing measurably, then switch back. It would be interesting to know which large companies have been trying it out and then deciding it's costing them too much money and switching back. > We ARE inherently lazy and most of us will ignore nearly any best practice or principle once “that deadline” gets too close. Sorry, this just means you're a shitty developer and/or can't manage deadlines very well. > Still, you don’t see that many big Python and Ruby shops either (Google is an exception,) His exception is a pretty large one. And besides that, which companies has the author studied? I'm not going to comment on any of the Java claims, since I don't have that much experience with Java. All in all this article is incredibly biased towards Java and affected by large amount of disinformation about Javascript in general.

dotborg 14y ago

There was much more "magic" in CGI/Perl. The only "magic" in JS in fact is caused by browser vendors and have nothing to do with language itself.

FuzzyDunlop 14y ago

> Nobody actually does plain “JavaScript” programming for the web anymore, not really anyway. Do they use the core language? Yes. But we no longer use any of the built-in JavaScript->HTML functionality directly. Which is sort of a shame because there's stuff in there that totally obviates the need to haphazardly traverse the dom with jQuery. Finding the form an input element belongs to in jQuery: $('input').parents('form'); // or probably $('input').parent().parent().parent().find('form'); Finding the same thing using the DOM API: document.querySelector('input').form; You'd want to mix those two, in a real use case: $('input').on('click', function(evt) { var form = this.form; }); Then you don't even need jQuery to use the FormData API: // where `submit` uses XHR2 to make a request <input type="submit" onclick="submit(this.form)">

Groxx 14y ago
Unless you want to support IE7, that is. http://caniuse.com/#search=queryselector http://caniuse.com/#search=queryselector Not that I recommend doing so, but in many cases you don't have a choice. Or you started working on a project that originally needed to, and maintaining consistent style might lead you to use jQuery everywhere.
- FuzzyDunlop 14y ago
  Of course. My main point wasn't the use of querySelector per se, but the ability to access the exact DOM element(s) you need without crazy querying or traversal. While the DOM API isn't perfect by any means, and jQuery fills that gap really well, there are still times where the OOP nature of the DOM gets you exactly what you want with minimal faff. The other problem is the relative obscurity of it thanks to jQuery and crowd-sourced DOM documentation (via MDN).
  - Groxx 14y ago
    yeah, jQuery certainly eclipses everything else. Though I don't know what you mean by obscurity + MDN... it does seem weirdly anaemic for such a big / complex / important piece of the API, but I don't know if I'd call MDN obscure. Or, I hope it isn't, I find it wildly useful.

ctek 14y ago

We have an extensive JavaScript codebase at the large corporation I work at and by simply enforcing the use of ECMAScript 5 Strict Mode and verifying with JSLint we are able to catch most potential issues but then again, nobody there is writing large systems in JavaScript, only flourishes of browser-side interactivity...

mattacular 14y ago
I'm hoping Node continues to gain popularity. The idea of using the same language on the serverside and clientside seems too enticing to fail.

jarjoura 14y ago

Point 1: There is no other way to write client-side browser applications. Point 2: Node.js allows a team of 1-2 quickly get a server-side app up and running. Once a project takes off and needs to scale to a larger team, it's extremely easy to switch to and write C++ components. Point 3: Who cares if history is repeating itself or not. It's an impressive technology stack with huge corporate backers. Besides, Perl is still used and although nowhere near as cool, still works great for writing shell scripts.

azakai 14y ago

> a stack that is resilient enough to withstand sloppy code. There is no such magic stack that withstands sloppy code.