Will WebAssembly (Wasm) replace JavaScript?

Ever since JavaScript was created in 1995 it has formed a key part of providing interactive experiences on websites. However, since WebAssembly (Wasm) support is now available in major browsers, will it be able to hold out against the competition, or will WebAssembly replace JavaScript as the essential tool for client-side development on the web?

I think there are several factors that will drive or slow developers to adopt WebAssembly as a JavaScript replacement. These are, the current level of language adoption by developers, the existing library support available, how comprehensive the browser support is, and the experiences they allow developers to deliver to users.

Language Adoption

At the moment, almost 98% of all websites use JavaScript for client-side development. This is primarily due to it being the only real option (especially since Flash support ended in 2020). JavaScript can also be used for server-side development, which enables developers to use the same language for the client-side and server-side parts of their web applications, through platforms such as Node.js. This makes JavaScript very flexible, since you can learn the language once, and apply it almost anywhere.

Making the case for WebAssembly is a little more complicated. WebAssembly can be compiled from multiple languages, each with their own positives and negatives. In the end, I imagine developers will use the language they are most familiar with already. This would seem to leave WebAssembly as an equal with JavaScript, since both could be used for client-side and server-side development.

Library Support

Due to JavaScript being the only viable option for client-side web development, a large number of libraries and packages have been developed with it. There are currently over 1.3 million packages hosted on npm, covering a wide variety of functionality for developers to leverage in their own applications. This makes JavaScript faster to build with, since developers are able to use these packages for common functionality.

In addition to this, there are also a number of frameworks available to support client-side development such as Angular or Vue. The breadth of support available makes using JavaScript a very safe option.

In the case of WebAssembly, the libraries available will vary between each language. But it would allow developers to leverage existing libraries for that language, so long as they are able to be compiled to WebAssembly. This opens up the possibility of using a range of performant features which would have previously been unavailable or difficult to achieve in JavaScript, such as image or video processing.

However, one of the notable drawbacks of WebAssembly, is that it cannot manipulate the HTML page directly. At the moment, a Wasm module must use JavaScript to update or modify page content in response to user interactions or data changes.

Browser Support

Browsers have extensive support for JavaScript, with major browsers implementing a wide variety of Web APIs. These APIs allow JavaScript code running in the browser to access a some of the features of the device, ranging from the device location to connected Bluetooth and USB peripherals.

WebAssembly is also supported by the major browsers. So applications which use it already have a pretty wide reach. It is worth being aware, that the Web APIs allowing access to features of the local device are only available to JavaScript code executing in the browser. As a result, WebAssembly code cannot access these features directly.

This would seem to indicate that browser vendors see JavaScript as a very flexible way to expose increasingly complex device features and functionality to developers. Meanwhile, WebAssembly has to rely upon JavaScript to access these APIs. To me, it certainly looks like JavaScript has the advantage in this case.

Experience Support

Both JavaScript and WebAssembly are capable of running complex client-side web applications. They will both handle functionality such as processing request routing information, responding to data changes and processing responses for user commands. However, JavaScript has very mature support for these use cases and is likely to remain the first choice for many.

WebAssembly performs best in specific use cases. This is usually when more intensive processing, such as in image or video editing, or rendering 3D graphics is required. While it would be possible to perform these tasks in JavaScript, the performance would be slower than a specially crafted Wasm module performing the same tasks. This is due to WebAssembly being compiled during the build process; speeding up browser execution.

Summary

To conclude, will Wasm replace JavaScript? No. Wasm is intended to compliment JavaScript in browsers, not provide a replacement. This is reinforced by Wasm modules needing to use JavaScript to interact with the HTML page. 

The aim of Wasm is to support a variety of use cases that would be difficult or impossible to practically achieve through JavaScript alone. These could be rendering 3D graphics (such as in games), or other processing intensive operations (such as simulations). An example of this is Doom 3 running in a web browser, which uses Wasm to run the game and renders the graphical output to a HTML canvas. 

While Wasm opens the door to many exciting new opportunities, in my opinion, JavaScript will remain the standard for client-side web development for a long time. Even the WebAssembly website indicates that JavaScript “will remain the single, privileged dynamic language of the Web”.