WebAssembly will Break the JavaScript Monopoly

Since the 1990s the only standard language available to developers targeting the web developers has been JavaScript. This is a great thing and has lead to the thriving JavaScript ecosystem we have today. This has been a given for over two decades, but with WebAssembly it could change.

We've had complementary formats like Flash patching the gaps of HTML/CSS/JavaScript capabilitities. But along the way there was never an open, standards based and widely available technology for delivering binary executables. The closest thing was AMF from Adobe/Macromedia:

Action Message Format (AMF) is a binary format used to serialize object graphs such as ActionScript objects and XML, or send messages between an Adobe Flash client and a remote service, usually a Flash Media Server or third party alternatives. The Actionscript 3 language provides classes for encoding and decoding from the AMF format.

Action Message Format (AMF)

Where AMF was a proprietary effort, a new format known as WebAssembly is making it's way up the curve in web technologies. Essentially WebAssembly (AKA wasm) a binary format, which allows a more portable, size and load time alternative to the scripting language approach JavaScript uses.

Show me the "sauce"

JavaScript is always delivered in human readable / source code form to the browser and thus can be reverse engineered easily. Even if minification and uglification are applied to JavaScript, it is still source code - you can _always_ view the source. Even if the source looks horrible.

"Viewing the source" is a strenght of the web platform. WebAssembly aims to enable this with a special format used for debugging, exposing the secret sauce that makes the application run:

WebAssembly defines a text format to be rendered when developers view the source of a WebAssembly module in any developer tool. Also, a specific goal of the text format is to allow developers to write WebAssembly modules by hand for testing, experimenting, optimizing, learning and teaching purposes.

-- WebAssembly FAQ

The key difference is that you can natively use any programming languages or technologies to built WebAssemly applications. In the past you've always had to target JavaScript with your source, but with wasm you don't need to worry about that silly scripting language from the mid nineties.

The obvious example here being compiling directly from C/C++ code to WebAssembly using Binaryen, which is a derivative of Emscripten - a compiler that uses JavaScript as a target language. The wasm built components will natively interface with JS for interaction.

State of WebAssembly

WebAssembly is a new endeavor, announced on June 17th 2015. On March 15th 2016 there was a public demostration of the technology in the real world, using the Unity engine in Firefox, Chrome and Microsoft Edge browsers.

By the looks of it WebAssembly could be of the technologies (like JavaScript before it) that might have the long legs it takes to make it as a valid technology for years to come. There is a lot of work to do on the lower levels, but the large browser vendors are all backing the technology:

I wouldn't recommend every single web developer to dive head first to the deep end of the pool with WebAssembly, since it's a complementary technology to JavaScript. Like the name implies JavaScript will remain as the language that connects the pieces, but the heavy lifting can be done with Wasm - instead of trying to shoehorning every single thing to JS.

Just like Perl is the glue of the internet, JavaScript will be the glue of the browser.