Why a JavaScript hater thinks everyone needs to learn JavaScript in the next year

JavaScript is now a necessity.

I’ve long looked at JavaScript as a second-class citizen in the programming world. Early on, it was the source of numerous security problems; it was a nice bit of glue to patch together HTML applications with a bit of styling, but nobody would use it for serious code; and so forth. Java, Ruby, Python, they were the languages for doing real work.

But my attitude toward JavaScript has changed completely in the past few years. JavaScript has “grown up.” I’m sure there are many JavaScript developers who would take issue with that judgement, and argue that JavaScript has been a capable, mature, and under-appreciated language all along. They may be right, though you can write any program in any complete programming language, including awful things like BASIC. What makes a language useful is some combination of the language’s expressiveness and the libraries and tools available. JavaScript clearly passed the expressiveness barrier a long time ago, even if the ceremony required for creating objects is distasteful. But recently, we’ve seen some extremely important game-changers: jQuery, JSON, Node.js, and HTML5. JavaScript may have been a perfectly adequate language in the past, but these changes (and a few others that I’ll point out) have made JavaScript a language that is essential for every developer to know. If there’s one language you need to learn in the next year, it’s JavaScript.

The potential of Node.js

Node.js logoNode.js has the potential to revolutionize web development. It is a framework for building high performance web applications: applications that can respond very quickly and efficiently to a high volume of incoming requests. Although Node is a low-level framework that can build any kind of application, it’s particularly useful for building web servers. Its asynchronous event-driven paradigm is arguably more effective for web applications than the more familiar request-response paradigm.

Two things make Node particularly valuable, though. First, Google has started a revolution in JavaScript performance. This isn’t to say that at any given moment they have the best JavaScript engine available (though that’s a fairly good bet). But what’s certain is that Google took JavaScript performance seriously when other players didn’t, and in doing so drove Mozilla, Apple, Microsoft, Opera, and other vendors into a performance race. The result is that the JavaScript engines we have now are much, much faster than they were a few years ago, and are capable of running a serious web application.

Second, Node has benefitted from an enormous pool of JavaScript developers. Whatever language they use for the back end “server,” few developers don’t use JavaScript in the client. It may only be for bits and pieces of glue; it may be for sophisticated Ajaxian effects; it may even be to write full-fledged applications, such as Twitter or Gmail. But whatever the case, the number of JavaScript developers is huge. And authors like Doug Crockford have been pushing the idea that JavaScript, despite many warts, can and should be treated like a serious programming language.

At this point, writing Node applications is relatively crude: it’s a low-level library, about as close to the metal as you can get with JavaScript. It is not a full-fledged web framework, like Rails or Django. But that is certain to change. Lightweight frameworks like Express are starting to appear, and I have no doubt that we’ll see more full-featured frameworks built on top of Node.

I’ve mentioned the appearance of sophisticated web applications that run almost entirely in the browser. Those are hardly new — how old is Gmail? How old is Google Maps? But writing the client side of an application in JavaScript and running it on the browser is increasingly attractive. HTML5 takes this trend a step further.

HTML5 is about JavaScript

I’ve said many times that HTML5 isn’t really about HTML; it’s about JavaScript. What changes in HTML itself? There are a few new tags, which in and of themselves aren’t that difficult to understand. The power of HTML5 lies in what these tags allow you to create in JavaScript. A drawing canvas isn’t very useful without the code that lies behind it and creates an animation, a game, or a visualization tool. As soon as browsers supporting Canvas appeared, we saw hundreds of implementations of Asteroids as developers started playing with the new features. Some were crude, some were surprisingly rich. That work is entirely in JavaScript.

HTML5HTML5, then, isn’t really a major advance in angle-bracket-based tagging; it’s about enabling JavaScript to do more powerful things. The WebGL library (which is still bleeding edge) allows real-time 3D graphics inside an HTML5 canvas. HTML5 geolocation allows you to write location-aware applications in the browser (a basic capability for mobile phones). Persistent storage and offline functionality have enabled developers to write full-fledged applications, with the same functionality you’d expect on a desktop, that run in the browser. There have also been experimental libraries for adding multitouch capabilities. These are all really features of JavaScript. HTML5 just provides a structure for giving them meaning.

Furthermore, there have been significant advances in browser libraries that don’t require HTML5. JavaScript has long been the workhorse for implementing dynamic features in HTML. But there have always been two problems: browser incompatibilities, and the awkwardness of working directly with the DOM. The JQuery library has elegantly solved both problems, and is the basis for modern client-side browser development. But it’s not just JQuery. The Protovis and D3 libraries allow you to create complex interactive visualizations that run directly in the browser — for the first time, making the browser an important tool for data exploration.

JavaScript and databases, compilers and languages

The use of JavaScript has also exploded in databases. Three of the leading databases in the NoSQL movement, CouchDB, MongoDB, and Riak, are “document databases.” Rather than storing tables, they store documents. And for all three databases, a “document” means a JSON document, not a Word or Excel file. (Riak also supports XML documents and plain text.) While JSON has been widely adopted as a data exchange format (there are libraries for parsing JSON in almost all modern programming languages), it’s important to realize that JSON is really just a format for serializing JavaScript objects. So while you can use JSON with any language, it’s a natural fit for JavaScript development; and the fact that JSON has become a cross-language standard, rather than some Python, Ruby, or Java serialization format, says a lot about JavaScript’s readiness to take a role on a larger stage. But even more than that, all three of these databases have facilities for executing JavaScript as part of queries. In the coming years, I would not be the least surprised to see JavaScript and JSON embedded within other kinds of applications.

We’ve only seen the beginning of JavaScript development. At this year’s JSConf, javascript-to-javascript compilers were a big theme, and seen as a major trend for the future. Google has been the hotbed of compiled JavaScript. GWT is the first framework I’m aware of that used compiled JavaScript (compiled from Java). I have never taken GWT that seriously; a framework that exists just to save Java developers from having to use JavaScript just doesn’t seem worthwhile. However, GWT does some amazing JavaScript optimization in the process. Closure is a JavaScript-to-JavaScript compiler that does the same kinds of optimization. Traceur, which first appeared a few weeks ago, was designed to allow experimentation with the language itself: it compiles JavaScript with experimental language features into JavaScript that can run on any modern platform.

Finally, we’re starting to see some languages compile to JavaScript, much as we’re seeing JVM languages in the Java space. Some of the more interesting languages, such as Coffeescript and Kaffeine, are similar to JavaScript in style, but focus on smoothing out JavaScript’s rough edges. Do you find the JavaScript object model interesting, but awkward, and are you put off by the ritual you need to go through to create a working object from a prototype? You may find Coffeescript a significant improvement. In addition to smoothing out the object model, Coffeescript adds features like list comprehensions, and does away with most of the curly braces. As in Python, indentation serves to delimit blocks.

Web servers, rich web client libraries, HTML5, databases, even JavaScript-based languages: I see JavaScript everywhere. If you have avoided JavaScript, this is the year to learn it. There’s no excuse — and if you don’t, you risk being left behind.


tags: , , , , ,