JavaScript is the new Perl

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.

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".

I've seen a lot of silly Ruby / Java / Scala code to buy this line of argument.

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?

> 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.

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.