A brief and incomplete history of how WebAssembly came to be
Those who cannot remember the past are condemned to repeat it.
The famous phrase, by George Santayana, is of special relevance in computer sciences. I've been in this field long enough to see patterns and technologies become a fashion, then be replaced by new shinier techs, and just a few years later come back as the next big thing. This is happening right now with the functional programming paradigm, which is experiencing a revival after 40 years of lying dormant. Don't get me wrong, I'm not against this cycle, I think its needed to keep evolving. What I don't like is discarding everything to move to the newest thing, just because everybody is talking about it. Anyway, that's not the point of this article.
I like looking at the history of things, how they come to be. That is why it is no wonder that when I first got interested in WebAssembly, I wanted to know how it originated, a quest that took me on a trip back in time almost to the origins of the World Wide Web. Let me take you through it.
The year was 1995. Microsoft launched a massive marketing campaign for its new revolutionary (for then) operating system Windows 95, and America Online and Prodigy started offering access to the World Wide Web for the first time.
As the popularity of the World Wide Web exploded, more than doubling between 1995 and 1996, developers turned to different solutions to take advantage of the platform.
Java, publicly launched that same year, promised total portability and targeted the web with their Applets. It is easy now to hate Java Applets as a technology, but for a long time, it was the preferred way to bring application programming to the web in a cross-platform manner.
Microsoft, of course, also provided an alternative to Java Applets. By bringing support for ActiveX controls to their Internet Explorer 3.0 (1996) browser they intended to capitalize on Windows developers eagerness to port their code to the Web. ActiveX was hard to secure, and not as portable as Java Applets, but it was very successful in enterprise Intranet applications, and I bet there still are some apps within big enterprises or government corporations that use it and run only on Internet Explorer.
With the goal of bringing C/C++ development to the browser, Google launched in 2014 their Native Client (NaCl) SDK. NaCl allowed compiling C/C++ code for using it on the browser. However their security model and general architecture made it really hard to be ported to other browser engines beside Chrome, and it was rejected by the rest of the vendors.
The almost simultaneous effort from Google and Mozilla to compile C/C++ for the web made evident the need for a standard solution to this problem.
It was something unprecedented and unexpected. The teams of the 4 main browser engines, which have a hard time agreeing on the semantic of CSS attributes, managed to reach an agreement with regards to a standard binary format for the Web: WebAssembly.
Even more incredible was the speed of development. Less than a year later, on March 15, 2016, WebAssembly was demonstrated running Unity's Angry Bots in Firefox, Google Chrome, and Microsoft Edge.
On March 2017 the initial phase of the MVP was declared complete. And by the end of September 2017, Safari 11 included support for Wasm, finally completing support on the main 4 browser engines, and making WebAssembly the first binary format universally supported on the Web Platform.
2018 and the future
We're slowly seeing the huge impact of WebAssembly on the web. Autodesk just launched a version of Autocad for the web taking advantage of WebAssembly, and both of the main game engines already support it as their default compilation target for WebGL.
However, we're just getting started, and this is just the MVP version. Can you imagine what is the next big usage of WebAsembly? Will it unleash a second performance revolution on the Web?
Stay tuned for a next article, where I'll discuss the future of WebAssembly.