The last talk I attended at Philly ETE was by Luke Wagner1 2 on WebAssembly3, which is an intermediate assembly language for browsers to use. There are conceptually equivalent technologies in .NET and the JVM, so this isn’t a totally novel field. .NET in particular has a very complex security model – WebAssembly will too, but in completely different ways.
WebAssembly4 is the third generation of a project that began as Enscripten5, which allows C/C++ code to be compiled to Javascript. It sounds like most of the work in this area has been done for 3-D browser games, since Unity6 and a physics engine7 have been built with this, which at least demonstrates the commitment of Mozilla to move this beyond being a toy project. With access to the source code and sufficient motivation, one could presumably rebuild old ActiveX controls this way (e.g. Acrobat Reader or Flash).
At one point I played with a project called EmbroiderModder8, which lets you write files in formats for embroidery machines – Enscripten allows this to be run from within Node or a browser. Other example use cases include SQL Lite9, reading AutoCAD files, C crypto libraries10, language detection11 and mapping12.
Asm.js13 takes this a step further by defining a spec/subset of Javascript that narrows the scope of the language to operations that can be easily optimized at a machine code level.
WebAssembly4 is the final piece of this: a unified specification for browser bytecode. This has to work across multiple processor types, so some WebAssembly commands might translate to one instruction on x86 and two on ARM, etc. WebAssembly also requires certain commands to translate into multiple instructions to protect the user against security issues. Currently there is some limited support in Chrome, Firefox, and Edge.
This suite of tools exposes a problem with browser tooling- if you deploy code that runs bytecode in a browser, you want to be able to step through the original source, but for something like Unity this is potentially multiple gigabytes of source maps. My current experience with these is that they can be a bit flaky, especially when large, so hopefully this motivates improvements in this area (at least in Firefox).
Currently the WebAssembly team advises against thinking of this as a compilation target for Javascript14, because browser are already packed with Javascript specific performance features, which would be skipped if you used WebAssembly. One thing that will be interesting to see is how the file sizes of Javascript bytecode compares to minimized Javascript, one could presume this will be much smaller. For now anyway, I sounds like mobile app vendors are receiving a lot of commercial pressure to preserve battery life and bandwidth carefully (a little like the 80s, when database vendors weighed features using the current and projectjed $/megabyte storage costs).
Mozilla is also considering options for how to render the bytecode as text – right now everything renders as “s-expressions”, which basically look like Scheme.
Currently there is some interoperability between Javascript and C calls, but it sounds like future performance improvements are planned to make WebAssembly call browser APIs directly, rather than going through a Javascript bridge. Despite that the WebAssembly team doesn’t want to supplant Javascript, I think in the future we’ll start to see libraries like React or jQuery use bits of their code in WebAssembly, once someone figures out areas that actually are faster.
Also of interest, there is an experimental polyfill for asm.js in development15.
This is an interesting and complex topic16 that potentially will have a large impact on developers in the future. If nothing else, it helps to explain the complexity of a browser: these have going from rendering a simple document, to an entire platform like .NET or the JVM, while also bundling sizable developer tools, and being subject to significant security constraints.
- https://twitter.com/luke_wagner [↩]
- https://blog.mozilla.org/luke/ [↩]
- https://github.com/WebAssembly/binaryen [↩]
- https://hacks.mozilla.org/2016/03/a-webassembly-milestone/ [↩] [↩]
- https://github.com/kripken/emscripten [↩]
- https://unity3d.com/ [↩]
- https://en.wikipedia.org/wiki/Emscripten [↩]
- http://embroidermodder.org/news0.html [↩]
- https://github.com/kripken/sql.js/ [↩]
- https://github.com/tonyg/js-nacl [↩]
- https://github.com/dachev/node-cld [↩]
- http://www.ba3.us/blog/?p=644 [↩]
- http://asmjs.org/spec/latest/ [↩]
- https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-trying-to-replace-javascript [↩]
- https://github.com/WebAssembly/polyfill-prototype-1 [↩]
- http://mozakai.blogspot.com/2013/06/what-asmjs-is-and-what-asmjs-isnt.html [↩]