Is WebAssembly Really the Death of JavaScript?
Ehhhh… ¯\_(ツ)_/¯
I’ve seen so many articles and talks in the last six months titled, “WebAssembly: The Death of JavaScript”. Many different languages have threatened JavaScript’s existence, yet nevertheless, it persisted. So that leaves us with a few questions:
- What the heck is WebAssembly and how is it going to kill JavaScript this time?
- Why has JavaScript been undefeated in the ring thus far?
WebAssembly: A Very Brief History
WebAssembly’s website defines WebAssembly as the following:
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine.
So what does that mean? In layman terms, WebAssembly is a new kind of code that can be compiled (ahead of time) down into a binary format that browsers can read. This means that high-level languages (C, C++, Rust, etc. that are high-level in relation to WASM bytecode and WebAssembly text format) can be compiled down into a format that is legible to the browser. For developers that want to do some heavy computing on the web, this is a huge plus.
Not only is the binary compilation feature nice for high-level languages, but it’s also marketed as being fast. But various speed tests (Michael Bebenita, Winston Chen) have shown that it’s only faster in certain cases. This is definitely something to keep in mind if deciding to choose WebAssembly.
When it was first introduced in 2015, only a few browsers supported and were able to read WebAssembly’s format. Now, all major browsers (with the exception of IE 11, per usual) support WebAssembly. This acceptance by major browsers has been a major accomplishment for the WebAssembly team as well as proof of an inevitable development use case.
However, as it currently stands, WebAssembly has no knowledge or access to the DOM (Document Object Model). This means that user interfaces as we know them will still require JavaScript for onClick functions that open a modal and other interactive features.
Currently, WebAssembly has demoed its ability to live on the web through Unity-driven games. It also has a list of use cases where WebAssembly shines, in which most of these use cases are graphics heavy (games, augmented reality, VR, etc.).
JavaScript: A Longer History
JavaScript was created in 1995. Netscape was dominating the browser wars but caught wind of a new, competitive browser being developed by Microsoft called Internet Explorer.
The popularity of Java at this time heavily influenced Netscape’s decision to pursue a language that could run on the web that would create a full-blown application platform. Netscape was working on a deal with Sun Microsystems to put Java on the web at the same time that they contracted Brendan Eich to create a Scheme (generally a Lisp language) for the web. Java was/is a rather robust language for the type of users that would have been using it on the web at this time (amateurs, designers, etc.). Eich saw an opportunity to form a scripting language that was easier to grasp called Mocha.
Mocha solved the issue of interactivity on the web. Websites could have animation, click functions, hover effects, and things the web had not seen regularly yet. Mocha continued to evolve and later became the language we know and love today, JavaScript.
By the time 1996 rolled around, JavaScript had become so popular that the European Computer Manufacturers Association (ECMA) created international standards for the language. These standards evolved into ECMAScript which, like the language, have continued to evolve (currently on ES 2018).
A multitude of frameworks (jQuery, Backbone, AngularJS, React, Vue, Node, Knockout, etc.) were developed on top of this language to supply developers with new methods for solving what would otherwise be complex issues in JavaScript. These frameworks dominate the front-end market and continue to grow in popularity daily despite the fact that many languages have tried to take the web throne from JavaScript.
JavaScript Sits on the Iron Throne
Throughout its history, JavaScript has dealt with many challengers trying to usurp its reign. Throughout it all, JavaScript has always come out on top as the most-used client-side language with a large community of developers and resources. So who were the major contenders against JavaScript and how did they fall?
Java Applets
Sun Microsystems released Java Applets around the same time that JavaScript was released in 1995. They were a way to get Java running on the web. Traditionally, Java Applets were developed in Java, however, other languages like Jython, JRuby, Pascal, Scala, or Eiffel could be used as well. Java Applets depended on the JRE (Java Runtime Environment) which generally required a plugin for a browser and was a very heavy package to install. Java Applets don’t run on mobile devices and aren’t accessible to a screen reader. In addition, security was always a concern. Java Applets are now deprecated since Java 9 in 2017 and will be removed entirely this year (2018) with the release of Java 11.
ActiveX
Microsoft created ActiveX in 1996 to compete with JavaScript. ActiveX was officially supported up until recently (2015 to be exact) when Microsoft released the Edge browser, with no ActiveX support. ActiveX was always criticized for security concerns and lack of portability which brought on its inevitable downfall.
Flash
In 1996, Macromedia acquired FutureSplash and re-branded it to Macromedia Flash. In 2005, Adobe acquired Macromedia. Flash was a fantastic tool for its time and had a strong hold on its market. However, Adobe has begun to favor HTML5 to solve the needs that Flash once did. Not only that but in 2010 Apple restricted the use of Flash on its mobile devices due to poor performance. Inevitably, in 2017 Adobe announced that it will consider Flash end of life in 2020 and will cease support, distribution, and development of security updates.
Silverlight
Silverlight was a Microsoft competitor to Flash. It was created in 2007 and still exists today, however, the only browser that supports Silverlight is Internet Explorer 11. Firefox stopped supporting Silverlight in release 52 and Chrome stopped supporting it in 45. Edge, like ActiveX, was launched with no support for Silverlight. In addition, Silverlight has not been supported on mobile devices since 2015.
So Will WebAssembly Be the Death of JavaScript?
I don’t know. If I did, I would have a lot of money and would be writing Medium articles from my beach-side manor. But if I had to guess, I would say no.
To me, they solve two different issues: JavaScript adds basic interactivity to the web and DOM while WebAssembly adds the ability to have a robust graphical engine on the web. WebAssembly doesn’t solve the same issues that JavaScript does because it has no knowledge of the DOM. Until it does, there’s no way it could replace JavaScript.
Even if WebAssembly could access the DOM, JavaScript is so widely accepted and used that it would be massively expensive for companies to take it down and make the switch. Not only that, but JavaScript is so well known to developers that the wide-spread adoption of WebAssembly as a replacement would seem unlikely. The performance improvements of WebAssembly over JavaScript are only evident in certain situations, and even still, are not so significant that JavaScript using websites would be left in the dust.
Even WebAssembly’s FAQs states:
No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. Furthermore, it is expected that JavaScript and WebAssembly will be used together in a number of configurations
So, at this time, I think the answer is no. With a new release of WebAssembly that has DOM support and greater improvements to speed in all circumstances? Maybe. But since JavaScript has survived many competitors before, I think it will still reign champion.
