Mozilla strives to make WebAssembly as fast as possible. In recent versions of Firefox, calls between JavaScript and WebAssembly are now faster than non-inlined JavaScript to JavaScript function calls. Mozilla also is looking beyond an MVP state to make WebAssembly more useful for building applications.
Recently, Mozilla has optimized calls between the JavaScript and WebAssembly and also has made calls from WebAssembly to built-ins faster. Two classes of improvements led to these results: reducing bookkeeping by eliminating unnecessary work to organize stack frames, and cutting out intermediaries by taking the direct path between functions.
One scenario in Firefox where JavaScript to JavaScript remains faster than JavaScript to WebAssembly, is inlined functions -- where a function calls the same function repeatedly -- because the compiler copies that function into the calling function.
Mozilla also looks at the future of WebAssembly by looking at the sets of features needed to make WebAssembly viable. The MVP features for WebAssembly are considered complete:
- Compile target
- Fast execution
- Compact
- Linear memory
For WebAssembly to provide support for heavyweight desktop application developers, more features are needed:
- Threading - a proposal based on SharedArrayBuffers
- SIMD (single instruction multiple data) - under active development
- 64-bit addressing - planning
- Streaming compilation - in Firefox, active development by other browsers
- Implicit HTTP caching - under active development
For standard web development, the features needed include:
- Fast calls between JS and WebAssembly - complete in Firefox, active development by other browsers
- Fast and easy data exchange - several different proposals under active discussion
- ES module integration - proposal evolving, initial implementations under active development
- Toolchain integration - in progress
- Backwards compatibility - wasm2js tool
To meet the needs of JavaScript frameworks and compile-to-JavaScript languages, WebAssembly has further requirements:
- Garbage collection - two proposals under discussion
- Exception handling - early research and development phase
- Debugging - rough support in some browser debugging tools
- Tail calls - proposal under discussion
WebAssembly beyond the browser introduces even more requirements:
- Portable interface - proposal under discussion
- Standardized runtime - a few early projects under development
WebAssembly is just past its minimum viable product phase, and the specification and implementation are under very active discussion and development. To learn more about the present and future of WebAssembly, a highly informative introduction from mozilla is available, WebAssembly’s post-MVP future: A cartoon skill tree.