January 4th, 2013 by 
Lincoln Baxter III JavaScript is the new Perl
I don’t think we will see a “winner” of the browser-language wars any time soon, but there will be a winner. JavaScript hype is still through the roof, and with the discovery of a dynamic language in the browser actually works decently between late browsers, people are thoroughly excited; however, I’d akin this to people discovering Perl during the advent of C and C++. Does it work? Yes. Is it pretty? Not by a long shot.
Don’t get me wrong, I love Perl – I think it’s an incredibly powerful and fun language that now suffers from the bad reputation it acquired before gaining true object-oriented features – but, those who hate Perl hate it because it’s “too hard to maintain” and too “strange.” So if you want to talk about a strange language, look at JavaScript – it’s like Perl times ten. At least Perl has a consistent type inferencing and enforceable namespacing! (I think you’d have a hard time arguing that enforceable namespacing is a bad thing… global variable collisions can result in some pretty nasty bugs, particularly because it is easy to never see the downstream impact.)
Point being? As someone who has already gone through several language hypes and paradigm shifts in Computer Science (even in my relatively short 14 year experience,) JavaScript is a lot like Perl – extremely powerful, but a potential maintenance nightmare if one is not extremely diligent – and while I do like both languages, JavaScript just waiting for the next technology to come around and make it look like Perl does today: pervasive, but lacking enterprise adoption on large applications.
Let’s take a moment to talk about Perl.
Perl was never as popular as JavaScript has become lately, partly because we never had a reason to popularize Perl in startup culture – where a teenager in his bedroom can make the next twitter craze – and partly because technology was just not as hot or nearly as pervasive back then.
If you look at the current trends, Perl is actually being replaced on a fairly large scale by Python and Ruby (other dynamic languages,) which, depending on who you ask, solve some of the maintenance problems and complaints that people have of Perl, and JavaScript is very likely to go through the same life-cycle – to be superseded by Dart, or maybe a non-backwards compatible mode of ECMAScript. In the mean time, to work around some of these issues, JavaScript is still being used much like an Assembly language. (GWT, CoffeeScript, TypeScript all compile to JavaScript.)
Now where is JavaScript?
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.) There’s a similar explosion of JavaScript implementations on server side and in other languages, leading to issues with compatibility and runtime bugs. If you tried to use ActiveState Perl on windows, or JavaScript via Rhino in Java, then you know what I am talking about. This is improving now, but so has it also improved in Perl, which compared to JavaScript was far more stable.
Still don’t believe that JavaScript is the new Perl? jQuery and NodeJS modules, likened to a very distributed collection of Perl modules, are the glue that holds together the JavaScript ecosystem, provides browser compatibility, and it admittedly does a pretty good job; 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. This is seen over and over as the new wave of developers comes into corporate life: Larger companies try out new technologies all the time, then decide it’s costing measurably, and switch back to a stack that is resilient enough to withstand sloppy code.
We are even seeing a re-emergence of age-old discussions on, “how to effectively architect large-scale applications”, and how to keep from falling into the same pit of snakes that’s been around for years – snakes that are now very long in the tooth. These are thoughts and principles apply to any programming language, really, Perl, Python, Java included – so if you think the revival of this discussion will produce different results for JavaScript, then I think you are forgetting human nature.
We ARE inherently lazy and most of us will ignore nearly any best practice or principle once “that deadline” gets too close. Nobody ever goes back to fix their mistakes once the project ends, or once they get rolled onto a new team. Java has been the only modern language to show moderate survivability when exposed to corporate laziness.
“So if JavaScript is doomed to become the next Perl like you say it is, then what do we do in the mean-time?”
We do what we have been doing all along, because these are necessary steps for advancement. We continue to invest both in JavaScript, but also in technologies like Errai and GWT – two technologies whos’ growth echoes of an early 2000’s Java.
We should be mindful of the fact that while JavaScript is HOT right now, it does actually have programmatic and strategic shortcomings that must not be forgotten, ignored, or “shooed” under the carpet. If you show me a long-term maintainable solution for JavaScript that enforces the team/feature barrier and holds up against “corporate meltdown,” due to incompetence and laziness as application size increases, then I’d be willing to entertain the idea of using it for a bigger project.
Keep trying the latest frameworks and cool UI plugins; keep trying to bridge the server-browser impedance mismatch; find what works and what does not – JavaScript is not going away. We still have Perl apps out there, and whatever replaces JavaScript as a dynamic language (think ECMAScript 6, unless a non-backwards compatibility mode is introduced) will probably be viewed similarly to Python or Ruby vs. Perl today. Backwards compatibility will be a problem for ECMAScript because it is necessary to enforce these constraints; it is not enough just make them “available.”
Still, you don’t see that many big Python and Ruby shops either (Google is an exception,) so unless ECMAScript offers some of the same safety features of Java, it will probably end up much like Python and Ruby – “A little better.” In all reality, though, there is a big part of the JavaScript -> Perl/Python/Ruby comparison that we’ve omitted from the story to this point.
Java.
Java has eclipsed most dynamic languages in the corporation. We see new statically typed dynamic languages on the JVM practically every day to provide some more programmatic sugar and flexibility, but on bigger projects, Java is king. Now apply this to the JavaScript picture and you get a slightly different flavor of the same result. Not only are we seeing experiments replacing JavaScript with a similar dynamic language (Dart, CoffeeScript, or maybe just some necessary enhancements to JavaScript itself,) but in order to support large projects, we are also likely to see a type-safe revolution in the browser as well.
GWT is a good start, but progress has been slow – just like Java was back in 2002. We’ve waited 10 years to see Java turn into the actually very useful and extremely powerful technology that it is today. Without a doubt, Java has the largest ecosystem of shared libraries in any programming ecosystem. Java has seen ubiquitous corporate adoption. Java is taught at most colleges and universities, and while you might try to make the point that “Python is being favored over Java” in some schools now, this is really not because of its technical capability, but more about teaching a more general set of programming knowledge that may or may not actually be useful in a business environment. Functional programming, variable interpolation, and the lack of a separate compile step make Python an appealing educational tool, certainly when combined with a shell language interpreter. This does not change what we use in the enterprise, in our daily jobs.
For example. When I graduated with my BS in Computer Science, before moving to Red Hat, I worked first at one of the top 5 American mutual fund companies; a big bank. I was tasked with something that nobody else had been able to do before, using Java, and I said, “Okay fine, I can do this easily in Perl.” So I did it.
Success? Or something else?
The result was a nice pat on the back for figuring it out – it was even deployed to production, but since I had left the team shortly before the release, nobody could figure out how to make changes to my scripts, didn’t think to come ask me when environmental changes caused a failure, and it got abandoned and re-written in Java. Was that a good reason to abandon Perl as a solution? Definitely not, but there’s a lot to be said for using a technology that is safe, using a technology that enforces ‘some’ good practices (“training wheels” of type-safety), and using a technology that is well known among the industry. This will be the reality for JavaScript and its corporate replacement, unless it can catch up soon.
In the end, JavaScript is good for us, just like Perl. It pushes us to do better, pushes us to think outside the box, and pushes us to think twice about what we have been doing in the past. It certainly has its place, we can’t ignore it, and we must acknowledge that it is very good at what it does; but, like Perl and Python, it’s not the end of the line. Until we get our hands on the still evolving ECMAScript 6, which may alleviate JavaScript’s enterprise problems, we still haven’t seen our “Java of the browser” yet, except wait, yes we have. It’s Errai and GWT.
See you in 10 years, JavaScript. Until then, I’m going to practice my Regular Expressions.
Posted in OpenSource
The article is very interesting. I started programming using PERL and PERL CGI in 1990. It was really the only thing to use at the time. It was considered the "cutting" edge using CGI technology. Java came along in 1995 with JavaScript (promoted by Netscape with marketing flare) that allowed you to use Java in Applets along with JS for dynamic content. PERL/CGI became relegated to the same status that Java was with the advent of RoR since it was not the "hot" technology.
JS was left relatively abandoned until AJAX came on the scene and dynamic content update via DOM manipulation came to the scene. I agree that a lot of the reason for leaving JS alone was forgotten in the years between 1999 2005. The first real exposure most folks got to AJAX was using Google Maps, and Gmail.
The JS notoriety comes primarily from the browser incompatibilities and incompatibility between versions (IE). It does expose the weak underbelly of JS by relying on an embedded interpreter in the browser.
Mozilla Rhino has come a long way in making JS easier to use. It is part of the JDK, and will be replaced by Nashorn which will vastly improve its capabilities.
I am not sure what will come along to replace JS in the browser. GWT was popular, but is all but dead (no tomatoes). JavaFX Script is gone to be replaced by a new JavaFX language. Dart is still niche. etc., etc., etc. That being noted JS has had its rise, dormancy, and rise cycle. This is the same cycle as Java itself. Java is on the upswing currently, and the ability to do polyglot programming (Thanks JRuby guys for making it a reality) have made it even more popular today.
I am currently trying to improve my JS skills using… JQuery. I am a corporate developer and want solutions not experimentation during the day. It solves a lot of the JS problems that the browsers have. I don’t need to worry about it.
One day JS will be like PERL without a doubt. You can still find PERL running on application servers like GlassFish (I have blogged about it), and MoveableType is one great application that runs on PERL. CPAN is a great addition to PERL, but it took years to become real. I suspect someday there may be something like it in JS. JQuery plugins go in that direction as you noted. Sometimes going in the direction of PERL is not a bad thing. PERL does run on the JVM too. So if you like PERL, use Sleep (http://today.java.net/pub/a/today/2005/07/14/sleep.html).
You may find yourself using PERL + JS in Java with JavaFX embedded in HTML with a JS bootstrap plugin on their next page.
JS may become the next PERL, but not before Java becomes the next COBOL.
[…] Programming News: JavaScript is the new Perl I don’t think we will see a “winner” of the browser-language wars any time soon, but there will be a winner. JavaScript hype is still through the roof, and with the discovery of a dynamic language in the browser actually works decently between late browsers, people are thoroughly excited; however, I’d akin this to people discovering Perl during the advent of C and C++. Does it work? Yes. Is it pretty? Not by a long shot. Read full story => ocpsoft […]
[…] is an excellent article published last week by a founder of OCPsoft comparing where JavaScript stands in the space of […]
Finally someone is willing to bust the Javascript hype.
From get-go Javascript was designed as a single-page language. it never considered there’d be naming conflict outside the size of JS code required only for one page. Once you wanna build anything big with the wheels quickly come off and become unbearable.
Oh, c`mon!
Take a look at real JS application, wich was builded today. CoffeeScript, modules, events – future is now, and all ok with ‘anything big’.
At now JavaScript more than
alert('Hello world!');, much more!
One big difference between Perl and JavaScript is readability.
Perl, with its many uses of @, $ and % becomes unreadable soon. It’s hard to find Perl source code that’s really readable.
JavaScript is just as readable as any other C-descendent.
JavaScript has its bad parts. Is that a problem? Not really, you can choose to just not using them 😉
Are global variables a problem? Yes, so don’t use them. Are global functions a problem? Yes, so create your own namespace.
It’s that easy. JavaScript is not doomed, not for a very long time.
huh? the use of @, $ and % makes perl *more* readable! You can Instantly tell if you have a variable array hash or a reference to those data structures. Saying they make perl code unreadable is like saying long series of series of dots "." connecting "objects" make ruby or javascript "unreadable".
Qooxdoo does everything you want: oop, nameSpaces…
Also has a UI interface, object oriented based on data, models and not anything like jQuery.
You can also use on the server with node.js.
Files can be shared between the client and the server. They have the exact same structure!
On the client you can run an already made script to compile all your files, or only the used ones into a big javascript file (build…).
Java is the new Cobol buddy 😀 but you don”t see it yet because you got that ORA-345342 exception. Lookup your online stack trace @ developer.oracle.com
Java is still alive due to Lindy effect or inertia if you want.
JavaScript was and still is the most popular language ever, and will live longer than Java due to Lindy effect.
I must admit I made more money coding java then all other languages, but that does not change the odds, … time did.
No, Javascript is not the "new Perl". No, Javascript is not terribly pretty and has serious shortcomings. You know what Javascript is? Do you really want to know?
Javascript is the new JVM or .Net runtime bytecode interpreter. It’s an odd bytecode interpreter, you program it in a weird Unicode syntax. Nevertheless with the myriad of languages compiling to JS (C++, C, Haskel, Forth, Fortran, Java, Actionscript, Coffeescript, LLJS, HeapCoffee, Dart, Typescript, Brainfuck, Smalltalk, Lisp, etc.) It is already pretty much the "VM". And with the addition of source maps to JS, the distinction between JS and a VM gets blurred even further as you won’t even have to look at the generated JS for any kind of (traceback, step-trough etc.) debugging anymore (ugly (dart), pretty (coffeescript) or otherwise)
Thanks for an insightful and good-spirited article. As an unabashed Perl lover I just wanted to make one additional comment. It is interesting that Javascript is going through some of the same teething pains that Perl did. Python/Ruby are doing the same. I think that one of the strongest arguments for Perl is that it is clear that it has survived these pains. People are still using Perl.
With new frameworks like Mojolicious and Dancer and the venerable Catalyst, all coupled with the new object systems (Moo/Moose) and Plack/PSGI server standards Perl is seeing a new resurgence. The language has already had its teething problems and now its growing with the needs of the community who has stood by it.
I ended up writing a response to this on my blog – http://rtigger.com/blog/2013/02/01/theres-nothing-wrong-with-javascript/
TL;DR – there’s nothing wrong with javascript – most of the criticisms in this article could easily be applied to almost any language that is new to a developer or team.
Javascript’s biggest weakness is its low barrier of entry: anyone with little experience can copy a few snippets from the web and make a page that "works". And this is exactly what gave Javascript a bad name in the early days of the web.
But, if you take the time to actually learn the language, and learn it properly, it is an incredibly powerful and, dare I say, elegant language.
The namespacing problem is trivially solved with the module design pattern (for smaller projects) or AMD loaders like RequireJS (for larger ones); JSList/JSHint adds extra protection.
Javascript isn’t going anywhere. You have to understand the ecosystem of the web; everything has to stay backwards compatible. Sure, there are replacement browser languages like Dart or Brython, but even those require Javascript to work. Until the day two major browsers support another client-side language, Javascript will be king.
I never said JavaScript was going anywhere 😉 Perl and Java aren’t going anywhere either, they are also extremely elegant languages; however, each has their own set of contexts in which they either are, or are not, appropriate. JavaScript is not the ultimate solution, no matter how elegant it may be 🙂 I love perl, but that doesn’t change the reality of where it is useful and on the other side, how can be damaging.
Yeah, I definitely agree JavaScript isn’t the answer to Everything. Node is great for some stuff (preprocessing scripts, testing some code out quickly)… but I don’t think I’ll ever buy into it as a viable server-side language.
You talk a lot about your comfort with static-typed languages, and a desire to see that in JavaScript. You might want to check out Microsoft’s new TypeScript (http://www.typescriptlang.org/). It’s not my thing, but I’ve been working exclusively in dynamically-typed languages for the past decade.
Famous quote: Javascript is just like Perl in so many ways. Super ugly, super useful, huge prolific community, and version 6 will never happen.
@Lincoln Baxter, III & @John Yeary you both talk about a CPAN-like system not being available to js but I fail to see how npm(1), bower(2) and Jam(3) are not similar. Maybe I don’t get how profoundly different CPAN is, but all js dev I know use at least one package manager. And while github.com(4) is not a package manager per ser, it mostly consist of js libraries.
On another note, jQuery is a DOM library. Created to mitigate browser incompatibilities in DOM implementations – not in JS implementations. But yes, it does have some nice features that goes beyond that.
That aside, I do agree on your observations, just not on js packages.
1. https://npmjs.org/
2. http://twitter.github.com/bower/
3. http://jamjs.org/
4. https://github.com/languages
[…] articles in the past several days that take critical views against something I love and believe in. JavaScript is the new Perl is skeptical of the recent surge in the popularity of Javascript. Five Reasons Why Responsive […]
javascript has a massive and very active community behind it, it is the only — THE ONLY — language that currently runs natively, without any plug-ins and/or runtimes in a web browser, on any device, anywhere, doomed?
javascript is right now being used as to run web servers, PAAS, build tools, CIs, as a replacement for shell and perl scripts, thanks to nodejs and as a language to interact with noSQL DBs like mongo, redis, couch, doomed?
javascript on the server side is not going away, companies as big as ebay, microsoft and yahoo — https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node — have already embraced it, microsoft has even worked with joyent to develop azure — http://www.windowsazure.com/en-us/ — doomed?
companies like adobe are working with browser vendors to improve existing and add new APIs that will be accessed how? using, javascript! doomed?
javascript is the most popular language on github — https://github.com/languages — almost 3 times as popular as Java, this is just one indication of how many people use JavaScript, not just out of necessity but out of love, or why would they be contributing to so many JavaScript open source projects? doomed?
javascript is so popular that Java, in order to save itself, is trying to compete by releasing yet another language that runs on the JVM called nashorn — http://wiki.jvmlangsummit.com/images/c/ce/Nashorn.pdf — guess what it looks like? javascript! doomed?
you should do your research sirs. doomed?
doubt it.
p.s. java is becoming the increasingly cumbersome language to use on the server side, which is why nodejs is becoming increasingly popular and it’s not even at v1 yet!
Please see my last comment 🙂
May I suggest an update to JS Logo / Badge?
Here’s a JavaScript Badge with the official JavaScript Logo Yellow:
https://github.com/voodootikigod/logo.js/blob/master/registry.md#javascript-strict-web-badge
And here are the vector (svg and eps) files for it:
https://github.com/voodootikigod/logo.js/tree/master/specific-uses
And here is an example of all 3 badges together:
https://github.com/coolaj86/logo.js/tree/specific-uses/specific-uses
I love both languages and I agree that with the native regular expressions, javascript is very mighty.
There is an RPC project that makes a holy ( or unholy ) alliance of the two languages using JSON called Yote.
It’s on CPAN, its home site is http://madyote.com and here is an example of its use :
Server Side :
package Hello;
use base ‘Yote::AppRoot’;
sub hello {
return "Hello World";
}
1;
Client Side :
$.yote.init();
var hello_app = $.yote.fetch_app(‘Hello’);
alert( hello_app.hello() );
// outputs "Hello World"
I fully approve of this unholy alliance 😀 PErLScrIPt …. ©˙∆˚當†§ƒ†√¨∫ˆø∆π˚ˆæø˚…¬µ∂˜ƒ∫å߬∂…擃–ºª•˙ˆ˜˚¬≤≥…
The funny thing is that this very site runs on PHP, the much-maligned scripting language powering, oh, maybe half of all Internet traffic through its progeny. You know, WordPress, Wikipedia/Mediawiki, Facebook, etc.
I wonder what would have happened had Javascript, early on, mimicked the syntax of PHP, thereby aligning the dominant HTTP client and server languages?