JavaScript’s ever-growing importance still takes people by surprise. Every time I post about things JavaScript makes possible, I get pushback from people who refuse to be impressed by JavaScript. Why? Because it isn’t what they wanted.
In the course of a week, I get to hear from different quarters about how JavaScript is half Lisp, and terrible either because it dares to be half-Lisp or because it only manages to be half Lisp. Similarly, as functional programming has become more visible, I’ve heard more from people who think JavaScript programming is too functional or not functional enough. People disappointed in JavaScript because it doesn’t have strong typing are a constant, as are people who find prototypal inheritance perverse. JavaScript syntax—I’m sure someone must like it.
It’s tempting to tell the story of JavaScript as a series of historical accidents. Brendan Eich put together LiveScript, applying a variety of techniques to meet a particular set of needs quickly. Since then, we’ve been dealing with JavaScript’s shift from a simple object manipulation language to a much broader and more powerful toolkit, unable to change approach because of the unique dynamics of the browser world.
The more I think about this, though, the less I think it’s true. JavaScript has faced competition on various fronts for most of its existence:
-
VBScript was an early contender, one that was more approachable for at least some kinds of development, though it was hobbled by Microsoft’s ownership.
-
Java applets, of course, were supposed to do most of the work we do today with JavaScript-based web applications. Many of the applet dreams would have shrunk the Web to simple documents and containers for applets.
-
Flash carried its own banner for years. Of course, ActionScript is itself a dialect of JavaScript, but the tools and environment were very different. Flash and JavaScript development were generally seen as competitive, especially as HTML5 added multimedia features that had previously required Flash.
Perhaps all of those opponents were flawed, and perhaps JavaScript’s ubiquity was truly a strange accident.
Perhaps, though, JavaScript actually fits its role well. It’s survived the shift from event handlers specified in the HTML to unobtrusive approaches. JavaScript syntax has proven extensible enough to support chained function calls. JavaScript tools have adopted CSS selectors to simplify interactions with the document tree, cleaning up one of the longest-standing headaches. JavaScript’s asynchronous event handling has even found a new home on the server, a key part of Node’s approach to scale. Many of the shiniest parts of HTML5 are also JavaScript APIs, not new markup.
Even if JavaScript isn’t the perfect language so many programmers would like it to be, it’s proven remarkably flexible, adjusting itself to the needs of the moment. Its latest act, which I suggested may keep it from conquering the world through ubiquity, is even a disappearing act. The developers who’ve hated it for years may find its flexibility so powerful that they can compile other languages to it, rather than dealing with JavaScript directly.
I wonder, though, whether there’s another round of JavaScript appreciation to come. The years since JavaScript: The Good Parts have seen a steady increase in the number of programmers who take JavaScript seriously. Programming culture hasn’t yet embraced JavaScript as a first language—web developers may learn it as their first programming language, but programmers tend to start elsewhere. In a perverse way, compilation to JavaScript may increase appreciation of JavaScript’s flexibility (at least among a few who realize what’s happening).
JavaScript’s differences, though, don’t seem to have hurt it. Despite some pieces that seem odd to developers coming from other backgrounds, those differences have helped JavaScript usage evolve with the Web.
Coming soon: If you want to explore more of this, and in person, you should definitely take a look at the Fluent conference, at the end of this month.