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!
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.