JavaScript’s Days are Numbered

To say this is a bold and controversial proposition is quite an understatement. It seems like JS is expanding like an octopus, taking over everything. So how can I make such a bold claim?

This is not another article about how JavaScript sucks. Richard Kenneth Eng has that ground well covered. And Douglas Crockford can reply that if you do JS right, it is a functional paradise, full of pure methods, immutables and function closures. Leave that argument aside.

How did JS ever get so popular in the first place? Hopefully no one can dispute that it is for a single reason: it’s the only way to script in the browser. I mean, I know there’s TypeScript and CoffeeScript and so on but they still end up transpiling to JS. Hopefully no one is going to claim there would be such a thing as Node if millions of coders hadn’t already been fluent in JS out of necessity.

But soon that’s not going to be the case anymore, because WebAssembly is coming on line. If you don’t know what that is, it’s binary code, compiled on the server side, that can be downloaded and run just like JS. Right now WASM is no direct competition for JS. In demos so far, it’s used to create a graphics window through OpenGL in order to make blazingly fast online games.

The makers of WASM assure us all that it is not meant to be a competitor for JavaScript. Its role, as now described, is very similar to the role formerly played by client-side Java until browser users deprecated it due to security concerns. And we can all pray that it will soon put the stake in the heart of the execrable Flash, and we never have to update that stupid player again.

But even as they say that, they are putting in hooks for manipulating the Document Object Model. For that matter, who needs the DOM if you have a full interactive app in a window? Certainly it’s easier to make some text boxes or dropdowns or whatever you need than a first person shooter.

In fact, the original intention of the Java applet was much more ambitious than what it was used for. When Oracle released HotJava, it was meant to serve the role that JavaScript does now. We can imagine a universe where exactly that happened — where your browser downloads binary code for every app. Why didn’t it? The security concerns connected to applets weren’t known then, and if applets had become central to the web, likely someone would have found a way to fix that.

I think it’s clear that JavaScript became the web’s scripting app because it was so easy. There were no type declarations, no compiling, no declaring of classes or memory management. Heck, there was only one type of number variable! And if that wasn’t enough, you could look at the JavaScript of any site you went to and see how they did it! I remember the intoxicating joy of being able to sit down and write a program that anyone could run anywhere, and just put it online.

Making an app in WebAssembly is still really hard. First of all it can only currently be made from an app in close to the metal languages like C, C++ or Rust. And even if you know one of those languages there are no commercial or easily accessible public apps for making a WASM program easily from your source code.

So why would someone go to the trouble of writing a C++ program when JavaScript is so much easier?

Right now they wouldn’t, but that’s going to change.

First of all, JavaScript is not easy anymore at all. A modern frontend developer has to know how use a dizzying array of tools, from package managers like npm or bower, frameworks like Angular or React, transpiling languages like TypeScript, task runners like Gulp or Grunt and many others. And you can’t even really see the source of programs on the Web anymore because they’re compressed to incomprehensibility to save download time. There’s nothing wrong with that. Software engineering should be hard, and the expectations for frontend are high nowadays.

But if you’re going to go to all that trouble, why not just write a binary app and compile it? Big companies like Google and Facebook certainly must be thinking that. They can hire programmers to do whatever they want. So why hire frontend developers when they could just hire C++ programmers?

Furthermore WASM is going to become more and more accessible. The WebAssembly team is already working on making it compile from garbage collected languages like Java. And as demand rises, there will be more and more tools to make creating WASM easier and easier.

And demand will rise if more and more major sites are written using WASM. Everyone wants to do what Google is doing, even if it’s complete overkill. If you don’t believe me look at the demand for Hadoop.

The other day I was scheduled to have a Zoom conversation with someone online. But I forgot that I had a new phone and hadn’t downloaded Zoom or Facebook Messenger, which is how they usually send me the link. I texted them to wait a minute, and went to the Google Play store and downloaded and installed both apps in less than two minutes. That’s not quite as fast as downloading a web page, but it’s getting there.

All of the things that make modern JavaScript so hard are caused by the fact that you are writing a full app but working in an environment where users are downloading your source code and compiling it on the fly. Modern browser developers have made some fantastic tools like the Chrome V8 engine to allow that happen at amazing speed. But it will never be as fast or reliable as already having compiled code.

And when there is no more need for JS on the client side, do you really believe anyone’s still going to want Node servers? Yes, Node is great for throwing up an app quickly. But there are other languages that are just as good for that, like Python and Ruby on Rails. (It would be hilarious if I was wrong just about this and JS became primarily a server-side language.)

What if WebAssembly turns out to have the same security concerns as Java applets? It’s possible, but even if that happens something else will come along that does the same thing. The web was never made to create fully functional apps. It was just a way of sharing data, a successor to the GOPHER protocol. It became what it is because that’s what people needed, and there was no better alternative. Soon there will be.

Don’t get me wrong. When it comes to programming languages, what is dead may never die. They say you can still make a good living as a COBOL programmer from all the legacy systems still running it. Without even looking at it I’ll guess there is probably some thriving ALGOL community out there.

So there will always be some JS out there. But I predict its time as one of the main languages of the Web is going to come to an end. It won’t be fast. I’m talking over the scale of 15 or 20 years. So there, I said it. Fight me.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.