“By our powers combined...” Let's imagine the representatives from all major web browsers saying this line when they joined forces, in 2015, for creating a whole new format for compilation to the web. When the WebAssembly support “revolution” began.
And there's no one in the digital landscape who can honestly admit that they saw this coming!
That after only 2 years all four major web browsers, Firefox, Chrome — the first 2 to enable support for WebAssembly by default — Safari and Edge — that joined the WASM “gang” the past few weeks — would officially run WASM code on the web.
How did it all begin? How did we get this far and (most of all): what can we dare to expect from a WebAssembly-influenced future of web?
An Unexpectedly Promising Start
Let's start with the “I have a dream...” type of beginning!
Work on WebAssembly started in 2015. Its team of engineers' dream (a dream nourished by all other web browsers) was to create a technology/set up a standard (or “format” if you prefer) for rendering application logic as optimized bytecode.
With near-native speed!
By the end of 2016 the team of visionaries — the W3C Community Group — had already added the last “strokes of brush” to the new WebAssembly standard's core features.
And only 7 months later, Google, Mozilla and Microsoft were already offering enabled WebAssembly support in their browser previews.
A major boost and a positive shake-up for the development team behind it, which no later than March 2017 was already concluding work on the new standard. And a consensus of all major browser vendors on the initial version of WebAssmely version was reached.
Then, it simply followed its roadmap and started to stir waves in the digital arena:
From then on, in the months to come, WebAssembly support started to be shipped along with the newest versions of all the 4 major web browsers.
The WebAssembly Standard: Benefits That You Can Reap
And the valid question that you might be asking yourself right now must be:
“And how do I benefit from this new standard? From the WebAssembly support now enabled, by default, in ALL 4 major browsers?”
- not only that WASM “was designed from the ground up to be fast” (Jay Phelps, Netflix senior software engineer, said), but also to guarantee you a higher level of protection: the WASM format code is much safer since it executes within the web browser's own security sandbox
- bytecode, thanks to its conveniently structured data format, is easier for web browsers to read and parse
What WebAssembly Support in All Browers Means for Developers?
As for your development team, as already mentioned, using the WebAssembly code compiler opens the gates to a whole new world of options: C, C+, Rust...
With more statically typed language support to come!
Moreover, broad Webassembly support at the web browsers' level can only mean that they're free to experiment. Since the great majority of end users now have WASM support automatically enabled in their web browsers of choice.
- your team of developers gets to perform their “coding experiments” in a programming language of their choice
- compile their code to a bytecode format
- … which then the web browser can execute within a virtual machine!
Safari and Edge: The Last 2 Browsers to Join the “WASM” Gang
With Firefox and Chrome as the “early adopters” of the Webassembly standard, it was about time that Apple and Microsoft shipped WebAssembly support in their Safari 11.0, respectively EdgeHTML 16 browser versions, too.
And it's finally a wrap! It's been a few weeks already since all 4 major web browsers are officially capable to run WASM-formated code.
What Next? WebAssembly In the Foreseeable Feature
In other words: what does using the WebAssembly code compiler at its full potential mean?
It's designed to make it possible for any kind of app (the largest ones, with a high demand of CPU, being the main target) to run on the web reaching the same performance as if it would if it was running locally, on the end user's PC. As if it was a native app.
What do you think? Will WebAssembly mark the “birth” of a new kind of native-like apps running on the web instead?
… and developers' “liberation” from the preconception of a “universal language”?