Advertisement
Motherboard

Is WebAssembly the (Eventual) Death of JavaScript?

A joint project between Mozilla, Google, and Microsoft could change how the web is programmed.

by Michael Byrne
Jun 24 2015, 11:00am

Image: Ruiwen Chua/Flickr

You won't hear too many web devs saying it out loud, but there is a world beyond JavaScript. The ruling language of web applications and interactive websites, JavaScript seems as much a cornerstone of the web as C is to conventional software.

Indeed, a critical piece of browser development is a JavaScript engine, which is a sort of virtual machine that takes JavaScript syntax and interprets it into instructions that can be executed by a browser. It's not terribly pretty and, what's more, it limits client-side web applications (those executed within the browser) to being written in JavaScript, which isn't very much in the spirit of programming and, well, JavaScript is also kind of crappy.

But JavaScript also can't help it for the most part. It's very much the product of evolution—evolution being a process of finding just good-enough solutions—and not super-long-term thought. So, as web applications take on more and more roles formerly handled by the sorts of software you'd normally download and install and run via an operating system like Windows or OSX, it makes a lot more sense to have a low-level development environment, where any number of languages can be compiled (translated) to a uniform machine-friendly syntax, which for an operating system like Windows or OSX is asssembly language or ASM (or MASM, for Microsoft assembly language).

Browsers don't really have a bytecode assembly language in this sense, however, which is where WebAssembly (WASM) comes in. This has been getting some press in the past week thanks to an announcement by JavaScript creator Brendan Eich that development will begin on a definitive WASM, a meta-language that will in the immediate future be very intimately linked to JavaScript, but will eventually have its very own life.

Crucially, WASM development will be immediately open to all comers. "A W3C Community Group, the WebAssembly CG, open to all," Eich writes. "As you can see from the github logs, WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks. I'm sorry the work was done via a private github account at first, but that was a temporary measure to help the several big companies reach consensus and buy into the long-term cooperative game that must be played to pull this off."

There are a number of transpilation tools that do allow for the usage of high-level general-purpose languages like C++ in building web sorts of things, but taking one high-level language and having it converted into JavaScript so it can be executed as plain-text instructions by the browser is a rather clunky way of doing things. Often, you might as well just do the damn thing in JavaScript at the outset.

There does exist a programming sub-language known as asm.js, which is designed to implement languages like C in a subset of the JavaScript language that's tailored towards lower-level operations like memory management. This is a big advantage (depending on who you ask and how they use code) of C and C++ in the first place: They're memory-lean and, if used correctly, they can also be very fast. This gets to be pretty important once we start programming software for embedded systems—like an Arduino controller, for example, or an ATM machine or the computer inside an MRI machine—that offer only limited processing and memory resources.

"WASM should relieve JS from having to serve two masters."

So, the very basic idea of WASM is that I could take a language I actually like, like Python or C++, and write a web application in that language and the WASM compiler will convert it into a form of browser bytecode, which would exist in binary form rather than the plain-text of JavaScript. This would occur in a way analogous to writing a program in Python or C++ in the normal way and it being compiled into an assembly dialect corresponding to actual machine instructions.

As Eich notes, in the beginning WASM would be developed in close concert with asm.js, but the two would naturally diverge in the future: "A secondary consideration: JS has a few, awkward corners even in its asm.js subset. Finally, once browsers support the WebAssembly syntax natively, JS and wasm can diverge, without introducing unsafe or inappropriate features into JS just for use by compilers sourcing a few radically different programming languages."

Yes, "awkward corners." It's probably the most immediate why? behind WASM itself. Even with the relatively optimized (or optimizable) asm.js subset, we are still after all converting from high-level language to not just another high-level language, but a high-level language that is JavaScript. And there are a lot of problems with JavaScript, as revealed by the bazillion articles and blog posts that searching some combination of "JavaScript" and "sucks" will yield. (This talk from Gary Bernhardt at PyCon 2014 is a good and reasonably neutral place to start though.)

JS fans need not be alarmed, however, according to Eich, who continues, "No, JS isn't going away in any foreseeable future. Yes, wasm should relieve JS from having to serve two masters. This is a win-win plan."

That said, there isn't a really great reason for it to stick around forever. JavaScript won client-side web programming because it was there, not because it was the very best thing for web programming. It will remain in existence for precisely as long as people keep using it.