I’ve never seen a technology lay down its primary advantage and prepare to hand over its ubiquity. I’m proud of JavaScript for doing this, and I’m sure that in the long run this will be good for the Web, but in the meantime I’m wondering where WebAssembly will take us.
Brendan Eich’s announcement of the effort makes clear that this builds on the earlier asm.js (and Google’s similar PNaCl), a highly efficient JavaScript subset that compilers of other languages could target. Eich enjoyed using Unreal Engine for demos of the speed asm.js could provide, but compiling to JavaScript, even weird JavaScript, still needed to go through a JavaScript parser. (Other approaches compiled to more comprehensible but less optimized JavaScript.)
WebAssembly – wasm – skips that final step, producing a binary format, technically a compressed AST encoding. Unless you’re going to be building compilers, you can compare wasm to a bytecode system. There is a text format for debugging, but the binary emphasis yields substantial extra speed as it skips parsing and minimizes decompression.
As important as any of the technical details, though, are the politics. Right now, it looks like all four major browser engine groups – Mozilla, Chrome, Microsoft, and WebKit – are in. On the compiler side, LLVM has been a key component for C and C++ support. These parts aren’t all cooked yet, but past experience in similar work suggests that they’re poised to move quickly.
Right now they’re targeting C and C++, which makes sense given how much of the world either uses those languages or uses them as a foundation. In the long run, though, this opens up browser programming to any language that fits this architecture and whose creators are willing to specify wasm as a compilation target. I suspect we’ll also see another explosion of frameworks, this time as developers figure out how best to express Web activities in a wide variety of languages.
For those who’d like to do more, the note in Eich’s announcement about being “in the long run able to diverge from JS’s semantics” is intriguing. I wonder whether this might let WebAssembly go further than the Java Virtual Machine (JVM). I’m guessing it’s too much to hope for Erlang-style lightweight processes and message passing, but we’ll see!
I’m sure a substantial group of developers is shouting “I’m free!” as they dream of a world in which the Web no longer forces JavaScript upon them. They may be right, eventually. Other developers are likely plotting a version of JavaScript that is just the good parts.
I even hope for another JavaScript renaissance, one in which the language is freed of the burden of carrying programmers who relentlessly insist on writing JavaScript that looks more like their other preferred programming language.
In the meantime, I expect that JavaScript will keep growing, secure in the knowledge that whatever comes next will likely work smoothly with JavaScript, even if in the end it isn’t JavaScript.
What language do you want for the Web?
This post is part of our ongoing exploration into the explosion of Web tools and approaches.
Public domain engine room image via Pixabay.