Depending on who you speak to, WebAssembly will kill Javascript, WebAssembly will enhance Javascript, and WebAssembly will merely appeal to a small subset of die-hard developers working on problems that require lower-level bare metal solutions written in a compiled language.
A lot of work has gone into reducing the performance issues that have plagued WebAssembly regarding making JS calls (especially when working with the DOM). Efforts seem to be focused on making WebAssembly more than a memory-siloed thing, but rather a viable alternative for anyone wanting to work mainly within the confines of WebAssembly.
The thing with accessing the DOM in WebAssembly applications that need to do so is you still have to go through Javascript. To my knowledge, there are no plans to allow for direct-DOM access via WebAssembly, but who honestly knows.
Since its early days of development as a specification, WebAssembly has been designed to complement and work alongside Javascript, not replacing it. There are no important aspects of WebAssembly that wall themselves off from Javascript. The two can communicate with one another.
An ongoing feature built into WebAssembly is garbage collection which will then share these objects with Javascript and allow them to be accessed. But, as always with these proposals, who knows if it’ll be accepted or the final implementation will resemble that of the initial specification.
While Javascript is great for building UI’s such as web applications and websites, you can fall into performance traps when you’re building GPU/CPU intensive applications that go beyond the limited capabilities of modern browsers. An exciting application area is lower-level graphics, allowing things like Virtual Reality in the browser to achieve the required low-latency and high-framerate performance necessary for a smooth experience.
One of the areas that WebAssembly has the potential to be used in is gaming. A port of Doom 3 into WebAssembly has proven to be a huge success. Figma famously made the early move to use WebAssembly in 2017 and saw substantial performance benefits.
As we advance, you’ll not only see games take advantage of WebAssembly, but another promising area where I believe you’ll see some WebAssembly innovation is blockchain. Imagine a blockchain running inside your web browser, which could be used to build decentralised applications or as a stand-in for traditional databases.
I also envision web frameworks and libraries using WebAssembly for their virtual DOM implementations such as ReactJS. Imagine if the dom-diffing algorithm used for the Virtual DOM was moved inside WebAssembly, freeing up the main thread for crucial UI tasks and ensuring smoother frame rates?
As you can see, many of the possible use-cases for WebAssembly will still have some UI component, and that’s where CSS, HTML and Javascript will still be needed to create rich interfaces. Still, WebAssembly will allow developers to move intensive UI-blocking work outside of the browser. It will result in better performing web applications that run on newer and older hardware more smoothly.
So, to answer the question (if the answer wasn’t obvious enough), WebAssembly will not replace Javascript. If anything, WebAssembly makes Javascript better.
Great clarification! No doubts left.