Alexei Boronine's blog, resume & projects.

Why JavaScript Still Sucks

I was among many developers that recently rediscovered JavaScript. Indeed as a very capable language. But after using the new JavaScript for a solid year, I came to the conclusion that JavaScript still sucks. And no, I’m not talking about its wacky comparison operators. There is a deeper problem, and a solveable one at that. Let me explain.

No Nonsense

I must’ve been 13 when my dad gave me my first programming book. I was overjoyed to find that under the hood, computers were not a tangled mess of wires and clockwork, no, the code was clear as day. I felt like I knew it all along, and in a big way I did. After all, what is code but a formalization of rational human thought?

Now, in all honesty I was expecting a Java book. I googled something along the lines of "is JavaScript and Java the same language". Turned out they’re not, and so, Java ended up being my second. I didn’t even get through the introduction before the first problem appeared: my mom and stepdad didn’t want me installing software on the family computer — I was left without a Java compiler. I remember double checking my code before uploading it to an online compiler, then waiting, downloading the jar… rinse, repeat. Boy was it tedious.

From my perspective back then, JavaScript was truly a no-nonsense language. You whip up an HTML file in Notepad, open it in Internet Explorer and you’re set. There were no classes, no private and public methods, no final variables. I didn’t know the word "overengineered" back then, but it would have described exactly my impression of Java. So:

  1. No compilation
  2. Ubiquitous platform
  3. No advanced language features
  4. Oh, almost forgot: View Source!

Why would a great language like that be so hated?

Ad-hoc Hell

Here’s the problem: JavaScript programs inherited from their language a complete lack of design guidance. Everything was ad-hoc:

  1. No OOP. I am not familiar with any other way to structure imperative programs. Yes, JavaScript has a rudimentary object model, but literally no one knew how it actually worked.
  2. No standard library. Copying functions from forums and pasting them into your code. Not fun.
  3. No module system. Constant scouting for download links and ridiculously long source files.
  4. No language resources. No high-quality resources (and hardly a single decent book) meant your best reference was misguided blog posts and newbie forum questions.

So, what happened to make JavaScript popular again?

Back in Vogue

I think what jump-started JavaScript’s reemergence was Google’s work on the V8 engine. Suddenly, JavaScript was fast. Real fast. Fast enough that people decided to bite the bullet and use it to write web applications.

Then Node.js came out with some wanky benchmarks and, more importantly, a promise for code reuse on the client and server, a promise not really capitalized on until recently, with the likes of Meteor and Derby. Things started to change for the better:

  1. Download buttons got BIGGER
  2. Node.js kind of sort of standardized an import system
  3. People started writing pretty good libraries
  4. Good resources started popping up

However:

  1. Still no OOP
  2. Client and server JavaScript still completely disconnected
  3. Documentation, even for high profile projects, is lousy at best

Why, why?

I think the root of the problem with modern JavaScript and the main reason that the language still sucks lies in a certain sentiment of the JavaScript community, the sentiment that JavaScript was a good language all along, it was just a misunderstood language. Um, no. JavaScript was a premature bastard baby, raised by frickin’ wolves. Stop defending JavaScript as a language and start embracing JavaScript as a platform, and as a compilation target.

Documentation

People can laugh at Java all they want but when I look at Java documentation I see exactly which objects I can make, exactly which parameters each method takes, exactly which errors they throw. The best I could hope for with a JavaScript library is a fancy piece of example code. This makes it nearly impossible to write correct software, unless you read the source code of the library you are using. Even such integral JavaScript projects as Express have lousy API documentation. (Ember’s excellent API documentation might be a counter-example.)

Syntax Sugar

The JavaScript community is too quick to dismiss syntax sugar. I think syntax sugar creates expressiveness. The same way you abstract repeating logic in your code, your language ought to abstract common idioms.

  1. It makes the code more concise.
  2. It helps communicate the *meaning* behind your code rather than the algorithm. I already know the array iteration algorithm, thank you very much. Stop repeating it and just tell me what you are trying to do.

As a coder, your main audience isn’t your computer, it is other programmers, including your future self. Yes, we can all feel cool writing tedious for loops, but who would honestly prefer reading for (var i=0; i<arr.length; i++) rather than for e in arr? As a side note, the JavaScript version of this loop is actually slower than its CoffeeScript counterpart, do you know why?

JSLint

As if being a JavaScript developer wasn’t painful in itself, JSLint comes and adds insult to injury. I imagine linting JavaScript as an embarrassing punishment in some kind of coding boot camp, akin to cleaning the toilet with a tooth brush. In fact, I think I would literally shave a yak instead.

On a more serious note, as programmers we should be looking for automation. Don’t you wish you could automate JSLint? Oh wait, you can! CoffeeScript generates perfectly linted code, which I find quite hilarious. Props to Jeremy for that one.

OOP

JavaScript’s object model is not enough. Prototypal inheritance is a low level feature that can be used to create a meaningful object model, but in no way constitutes one by itself.

This is part of the reason that JavaScript’s API documentation sucks so badly, how are you supposed to document your object-oriented code when your language doesn’t even have classes? How are JavaScript libraries, and, most importantly, JavaScript developers supposed to interoperate when we don’t even agree on how to instantiate objects?

What Are the Options?

Years have passed, laptops were replaced numerously, regimes crumbled, subatomic particles were discovered. JavaScript is still the same. How many years are you willing to wait for basic features? Following the pessimistic tone of this article, let’s first list the things that aren’t going to be an option:

  1. Mozilla’s own JavaScript 1.7 or 1.8. The former was released 6 and half years ago, but being backwards-incompatible, literally no one used it and no one ever will, same goes for the latter. Both dead on arrival.
  2. ECMAScript Harmony. The most recent Design by Committee sloth, an evolution of the above. Transitioning to this new ECMAScript is going to be an excruciatingly slow and painful process, especially since some of its features are incompatible with JavaScript. Not a solution unless you’re willing to wait for a decade.

And, finally, the viable options:

  1. CoffeeScript. The syntax is very nice and it supports classes. I think CoffeeScript is not the end, but it is a spectacular start.
  2. TypeScript. Builds on JavaScript to add optional static typing, which I, personally, am a big fan of. As pointed out by Mohamed Mansour and Dave Hodder in the comments, TypeScript goes further by implementing some ECMAScript proposals and perhaps ECMAScript will eventually borrow the optional static typing from TypeScript. Very interesting.
  3. Google Dart. A wholly new language that ships with a to-JavaScript compiler and some JavaScript interop but overall is not meant to integrate into the JavaScript ecosystem. I fail to see a compelling reason for this other than some Google engineers ignoring reality in favor of making a cool new language from scratch. As a coder I can understand that, but I think it will prove to be the language’s downfall.
  4. HaXe. Thanks to Laurence Taylor for pointing it out in the comments. This is a high-level language that compiles to JavaScript, Flash, NekoVM, PHP, C++, C# and Java (soon). I’ve never used it myself, but it looks really impressive.

Conclusion

One thing I am ready to bet on: the winner will be a compile-to-JS language. We aren’t ready for a transition yet, but we are making progress and even though many efforts diverge, they all pave the way for the future of the web. Regardless of which language wins in the end, I want to emphasize my main point: JavaScript as it stands today is painfully inadequate, we need to embrace the need for a new language and push forward!

Props to all the people making this happen and here’s to hoping that more Node developers divorce their JavaScript purism and join the ranks.

</script>