There's Nothing Wrong With JavaScript

I read a blog post today, JavaScript is the New Perl, about how JavaScript is “hard to maintain” and “strange”. It contains a few comparisons to Perl’s existence as a language, and closes with the author’s preference for Java in large projects and a personal ancedote about a Perl script he wrote as a new grad not being adopted. As someone who’s been using JavaScript in production for 6+ years now, I feel the need to counter with “There’s nothing wrong with JavaScript”.

A lot of the points the author brings up are extremely valid points: JavaScript can be ugly, it can be hard to maintain, it can be considered strange to anyone who isn’t familiar with dynamic languages. But these are points that can be applied to absolutely any programming language out today. If you throw me into C++ code, a language I have little familiarity with, I will probably say the exact same thing about C++.

The point I’d like to make is just because you’ve had a bad (or no) experience with a language / design pattern / anything in software development, doesn’t mean it’s the terrible and needs to be replaced. It means you need to spend a bit more time with it, figure out what problem it’s actually trying to solve, and determine if it fits into your project.


It’s true that JavaScript is getting quite a bit of well-deserved attention nowadays, which more or less started with the Node.JS framework and Coffeescript. Soon there were several languages that compiled to JavaScript, a new package manager in NPM, cross-device development using PhoneGap and other frameworks, and integration as a first-class citizen in Windows 8.

JavaScript is an exciting language! It has a low barrier to entry – all you need is a text editor and a browser. It has probably one of the biggest open source communities dedicated to simply improving and extending the language itself. There is always something new happening with JS – either with a new cross-browser UI control, a new package in NPM, a new language that compiles to JS, or a new platform that adopts JS as it’s programming framework. There’s a lot of hype around JavaScript, and it deserves every bit of it.

Use in Large Projects

As I said, we’ve been using JavaScript in production for 6+ years at our company, ranging from simple ajax-based updates and shopping cart flows, to full-fledged client-side applications in the browser. There has been some growing pains when it comes to things like code organization and maintainability, but those were the exact same pains when our company first moved to C# from VB, or when we started using XAML over WinForms. Any sort of new adoption is going to see those same problems, until developers get familiar and comfortable with the new tool. It’s no reason to damn the tool to extinction, or fall back on “tried and true” methods.

JavaScript does have some issues with package management, but what language doesn’t? Even those with package managers like NuGet, NPM, CPAN, Gem, and so on have some issue. And it’s imporant to note that (with the possiblie exception of CPAN) JavaScript predates a lot of those libraries. As you can imagine, it would be much harder to introduce a package manager once a language is established. Node.JS, as a contrasting example, had NPM right out of the gate and it’s been doing well. Arguably, CDN servers act like a type of package manager, referencing a specific version from a server and listing it as a depenedency via a script tag.

Issues like namespacing can be addressed by a little snippit of code, and concepts like modules are being provided by community-driven frameworks. ECMAScript 6 is also incorporating a lot of feedback from the community to add those open-source additions to the core language. And in most cases, if you truly understand the language’s prototype and functional nature, a lot of these complaints are non-issues in production code.

It Used to Suck

Before the “AJAX Generation” of JavaScript, it did suck. It was really hard to do anything well with it, mainly because of browser inconsistencies, a lack of any IDE or debugging tools, and numerous security flaws. With the introduction of community-driven client libraries such as Prototype, jQuery, and others, as well as the AJAX revolution that drove Web 2.0, browser teams were motivated to add new and extensive debugging tools and support for advanced JavaScript scenarios like document manipulation and HTML5 APIs. Those improvements lead to even more innovation, using Chrome compoents to create Node.JS as one example. JavaScript is not the same as it was 9 years ago, and people who have written it off because of old behaviour need to take another serious look.

The Replacement of JavaScript

The author alludes to the replacement of JavaScript in the browser several times in his article, citing languages like Dart, CoffeeScript, GWT, Erral, ECMAScript 6, etc.. And that’s fine. If another tool steps up and is able to address the problem(s) that JavaScript is currently dealing with, then great! It’ll advance the web dev community and everyone will benefit. Until then, JavaScript is what we’ve got, and it’s doing a damn fine job.

I’ll finish with a quote I found eariler in the week:

There are only two kinds of programming languages: those people always bitch about and those nobody uses. – Bjarne Stroustrup