Will JavaScript take over the programming world?

Not if it surrenders its ubiquity advantage

Last July, I had to give an impromptu talk. What came out, much to my surprise, was roughly “JavaScript will dominate the programming world.” I didn’t say that JavaScript would dominate through sheer popularity – JavaScript may in fact top the list of languages disliked by programmers, because so many programmers use it as a strictly secondary language beside their preferred server-side toolkit.

Instead, I argued, as you’ll see in “Concentration,” that JavaScript would win by ubiquity, offering a solution that fit well enough in both clients and servers. While I still think JavaScript could indeed “fit well enough,” the winds have changed and JavaScript may be about to surrender its ubiquity advantage, as you’ll see in “Dispersion.”

Concentration: The Wrong Story

After decades of a Cambrian explosion, we may finally see a concentration in the use of a few programming languages and a corresponding decline of many others, leaving us with three main families of programming languages. (Remember, this story is wrong.)

C and its immediate relatives will always be with us, providing a thin abstraction layer just above the processor. Functional languages that trade off ease of use in favor of extreme reliability, scalability, and manageability will continue to thrive in a small but ever-more important space. The biggest changes, though, will happen to the currently diverse general-purpose languages.

General-purpose languages, the tools that programmers have used to quickly assemble programs without having to sweat the details of memory management and data structures, are approaching a turning point. There is nothing intrinsically wrong with Perl, Python, Ruby, PHP, Java, C#, or many others, and they will continue to be used for a long time. However, their growth rates are going to shrink dramatically.

What innovation could unseat those champions? It’s “The VB of the Web,” a language that was patronized and dismissed for over a decade. JavaScript may not have had much respect for a very long time, but it has two major advantages over all of its general-purpose competitors:

  • Ubiquity – it’s on practically every computer sold today, somewhere, and any programmer who’s gone near the Web has at least thought about it.
  • Power – the JavaScript renaissance continues to demonstrate that this language is extremely capable, especially in the ever-growing number of cases where asynchronous communications are necessary.

JavaScript snuck in. For a long time, “write once run anywhere” was supposed to mean Java, with its armies of virtual machines for every platform. The browser was just a window onto a server-based world, with JavaScript providing a few key features on the client. As developers realized that the Web was the easiest way to create user interfaces for shared data, more and more programming activity shifted away from ‘classic’ GUI implementation to building web applications. As more and more Java development fell back to the server, JavaScript solidified its hold on the client.

While the Dynamic HTML boomlet of the late 90s vanished into the dot-com bust, Ajax returned JavaScript to prominence in 2005. Douglas Crockford’s JavaScript: The Good Parts made it clear that JavaScript was a first-class programming language, even if its take on objects was unconventional. Growing demand for more desktop-like user experiences led to massive growth in JavaScript programming, with more processing happening in the browser. That often (though not always) led to simplification on the server side.

Having achieved ubiquity as THE language (pretty much the only language) for client-side web programming, JavaScript is now poised to take over the server as well. It is not just possible to program the server-side components of a web application in JavaScript, but JavaScript has certain key advantages other languages can’t compete with:

  • JavaScript’s years of use in interfaces created a dominant callback style that works efficiently in pretty much any asynchronous communications situation.
  • Browsers now run on an incredibly wide variety of devices, from cellphones with slow CPUs and lousy bandwidth to speedy machines with lots of bandwidth. Using JavaScript lets applications decide where they want the code to run, and new frameworks (notably but not exclusively Mojito) can decide based on a given situation whether JavaScript should run on the client or the server.

It is probably possible to create a language with as much support for async as JavaScript, and a better syntax. It probably also makes sense to compile that language to JavaScript, as both CoffeeScript and Dart do.

The second advantage is much, much harder to overcome. It’s certainly possible for something like GWT to compile Java to JavaScript, but it’s a difficult thing to sustain. RJS (Ruby compiled to JavaScript) became a dead end pretty quickly. JavaScript may be a great target for compilers, as CoffeeScript and Dart are demonstrating, but those languages typically retain many of the restrictions and values of JavaScript.

The JavaScript community itself is evolving to support these new possibilities. Node is the hot and new server-side environment (complete with surprising support from Microsoft), but perhaps more importantly it’s spawning an ever-growing number of extensions and frameworks. Most of those are small pieces, but “full-stack” frameworks, notably Meteor, are emerging to cover the entire range of tasks from querying databases to helping users interact with that data.

Wait five years, and there won’t be much good reason to use other languages to build web applications. Wait ten years, and you’ll see applications written in other languages migrating to JavaScript because of the enormous ecosystem it’s building. Because so many programmers use JavaScript at least “part-time,” it’s not hard to find programmers for JavaScript projects. JavaScript’s lack of a corporate master, a difficulty in its early years, gives it an advantage moving forward because users don’t have to fear corporate agendas.

Other languages will probably not go extinct, but it will be much more difficult for them to grow. My suspicion would be that they find smaller niches, with Python perhaps holding on in the sciences, Ruby in experimental development, Java and C# in some corporate systems, and Perl in text processing and data munging. They will all still be good at what they do, but will face sharper competition.

I was, of course, wrong.

Dispersion: A More Likely Story?

I no longer forecast JavaScript taking over the general-purpose language space. It’s not because polyglot programming is more fun or even more powerful for most cases. It’s because I was wrong about the side effects of compiling to JavaScript.

When I first told this story, compilation to JavaScript was exciting but tricky. It was spreading from GWT to Dart to ClojureScript to CoffeeScript, but it seemed likely to always remain special purpose, buffering a larger shift toward JavaScript but incapable of slowing down a growing shift.

Over the last few months, though, I’ve been surprised by continuing conversations about JavaScript as a new assembly language – certainly more approachable than my distant memories of 6502, but similarly flexible. Asm.js broadened that conversation dramatically. While I remain uncertain that it will be the one true approach, it makes it very clear that the compilation approach can be more generic than I had thought possible.

Compilation approaches mean that “the JavaScript way” will no longer be the only way to do things in the spaces where JavaScript currently dominates. This frees developers who didn’t especially like the JavaScript way to work with approaches that are more comfortable to them. Even developers who are fond of JavaScript may take the opportunity to experiment with something different as toolsets grow and it becomes easier to do.

The Cambrian explosion I mentioned earlier may be returning, to JavaScript itself. Asm.js and related work moves programming another layer up the abstraction stack. Our processors seem capable of handling the known inefficiencies, and our toolsets seem prepared for another bout of rapid evolution.