Main image of article Is WebAssembly the Future of JavaScript?

WebAssembly is the next stage in the evolution of client-side scripting. In theory, it will improve on JavaScript’s speed. That’s not to say that JavaScript is a slowpoke: Incremental improvements were followed by the rollout of asm.js (an optimized subset) in 2013. But how much more can programmers tweak JavaScript? Hence the need for WebAssembly, which—while not a replacement for JavaScript—is intended as a “cure” for a variety of issues where JavaScript isn’t always a perfect fit, including video editing, encryption, peer-to-peer, and more. (Here’s a full list of the Web applications that WebAssembly could improve.) On its most fundamental level, WebAssembly is a low-level programming language and binary format for in-browser client-side scripting. It's portable safe bytecode that is designed for faster parsing (up to 20x) than JavaScript, with faster execution. WebAssembly has backing from developers at Mozilla, Google, Microsoft, and Apple, making it unlikely to suffer the fate of Dart, which was a Google-only venture.

Goals of WebAssembly

WebAssembly started out with simple goals, including support for C/C++ conversion (with other languages coming along later). The developers knew they’d need a polyfill to get around the issue of browsers not supporting WebAssembly natively at the start. The name “pollyfill,” coined by British developer Remy Sharp, is derived from PolyFilla, the British name for Spackle paste, and means a JavaScript script to convert wasm to asm.js for those browsers without native WebAssembly support. There's a prototype polyfill (JavaScript library) available on Github. The binary format allows WebAssembly programs to execute very efficiently, but you're also able to write WebAssembly in text (in .wasm files) and view the source of a WebAssembly module in a browser. (See the FAQ for better detail.) Creating for WebAssembly depends on tools such as Emscriptem and LLVM to convert C/C++. (Developers can switch from binary format to text and vice versa without losses.) Compilers for languages that target WebAssembly (C/C++, Rust, Go, C#) will eventually run in WebAssembly themselves, by emitting a WebAssembly module that a system can run. These will not be developed, however, until WebAssembly reaches its Minimum Viable Product stage.

WebAssembly Modules

WebAssembly’s main unit of loadable, executable code is a module. It can declare functions and global variables as exports that another module can import. Modules can be dynamically loaded just like ECMAScript 6 (JavaScript). WebAssembly code is represented as an abstract syntax tree made up of statements and expressions. Each function body consists of exactly one statement. All expressions and operations are typed, with no implicit conversions or overloading rules. Wasm instructions will operate on native machine types such as 32-bit integers, enabling efficient compilation.

Not Just for Browsers

WebAssembly’s creators don’t want it used just for desktop and laptop browsers; they also want it on mobile devices and Internet of Things hardware. In theory, WebAssembly’s intermediate representation (IR) should support both Just-in-Time and Ahead-of-Time compilation, making it potentially suitable for iOS as well as Android development. How long until the first WebAssembly App reaches the App store? A finger-in-the-air guesstimate puts it at 18 months. There's a whole lot of tooling needed, but with the combined resources (especially from Apple), don't rule it out.

The End of JavaScript?

WebAssembly is not there to replace JavaScript but to complement it. The key to this is integration with the DOM and Garbage Collected Objects such as JavaScript strings, functions (as callable closures), Typed Arrays and Typed objects. Module memory in WebAssembly can be accessed as an external ArrayBuffer from JavaScript. An entire application written in WebAssembly (or converted from C/C++) might have JavaScript or HTML as part of the UI.

Conclusion

It's still early days for WebAssembly but it could prove a powerful new tool for developers. There's an informal WebAssembly Community Group on W3C that's open to all (but you will need a W3C account to join); if you’re interested, check it out.