
JavaScript is the new Perl - ct
http://ocpsoft.org/opensource/javascript-is-the-new-perl
======
trimbo
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.

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

~~~
kalms
> The two languages are used in very different ways

I thought so too. JavaScript seems like it's filling a gap, and by doing that
it's ensuring its own survival. Either that, or we're forcing it into a
specific purpose (i.e event based manipulation, animation, data i/o), but the
end result will probably be the same. I have a hard time imagining something
else coming along, at least not as long as JavaScript is... well, everywhere.

Thank you for explaining Perl to me. A proper module system, compile-time
checking and the sort has, with JavaScript, been solved by using JSLint and
AMD. Well, almost. It makes the code easier to maintain. Although I'm sure
Perl is superior in that regard, it still works - and it works really well.

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

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

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

------
FuzzyDunlop
> 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
Unless you want to support IE7, that is.
<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
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
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.

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

~~~
fruchtose
I agree with a lot of what you said, but I can see one area where I can see
what the author is trying to say.

> _How is javascript like assembly?_

You're right that JavaScript is not like assembly; it's more like bytecode. A
number of different languages compile to JavaScript (CoffeeScript, TypeKit,
Fay), which is then interpreted. While the intent of JavaScript is that it
should be readable by humans, in practice this does not happen thanks to
production minification. This is more like bytecode. For example, you _can_
Java .class file with a hex editor, but you'll need software to do that, or a
hex editor and a lot of time.

tl;dr: The author _means to say_ that JavaScript is used as a building block
for other languages used to write client-side logic.

~~~
arnorhs
Ok, I can see that point. I guess the big difference is that not many people
write in bytecode, but a lot of people (majority in my experience, which might
change) write in pure Javascript

~~~
azakai
> I guess the big difference is that not many people write in bytecode, but a
> lot of people (majority in my experience, which might change) write in pure
> Javascript

That's purely a matter of preference. If you want, you can write in Java, C#
or C++ and compile that to JavaScript, many major websites use that approach.

The fact that many people still write pure JavaScript shows the opposite of
what the article says: People like it and are productive with it. If they were
not, they would more often write in something else and compile to it.

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

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

------
staticsafe
Site seems to be timing out here.

~~~
coroxout
Same here. No-image Google cache version here:
[http://webcache.googleusercontent.com/search?q=cache:QFxSoJi...](http://webcache.googleusercontent.com/search?q=cache:QFxSoJi4FgkJ:ocpsoft.org/opensource/javascript-
is-the-new-perl/&strip=1)

------
smosher
_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
If you replace “popular” with “visible”, then it makes a kind of sense.

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

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

------
azakai
> a stack that is resilient enough to withstand sloppy code.

There is no such magic stack that withstands sloppy code.

