Notes on the future of WASM and JS

These are literally my notes, from doing research on this topic. They contain the most important facts I've found, with supporting sources. I thought I'd share them since someone else might find these notes useful.

Scroll to the very bottom to read a high level AI generated summary of these notes.

WASM (WebAssembly):

• “A low level abstraction over modern hardware”.
• Will not outcompete JS in the near term.
  • But in future it likely will, due to threads and SIMD (which JS will never get access to, according to this).
    • SIMD (Single-Instruction Multiple-Data; a CPU instruction set for parallelism).
    • “Now, SIMD can be used for a large variety of applications. So you can use it for image or audio, video codecs, applications like Google Earth and Photoshop, or even machine learning applications on the web.” ref
• Will augment JS by enabling node and JS to outsource tasks (image manipulation/compression etc.) to other languages. But JS also has Web Workers for multi-threading / parallelization.
  • “most success with WebAssembly for algorithmic / compute-intensive tasks.” ref
• WASM has no native DOM access, so all libs accessing the DOM is doing it through the native JS DOM API.
  • «Since it can only load and store numbers, it needs to call out to JavaScript code to do anything interesting (create DOM nodes, make network connections, etc.). WebAssembly code is still inside the browser sandbox and can only use the browser APIs that JavaScript has access to.» ref
  • “Unfortunately, the DOM can only be accessed within the browser's main JavaScript thread. Service Workers, Web Workers, and Web Assembly modules would not have DOM access.“ ref
  • “In the future, this will get easier, proposals such as Interface Types are making it easier to interop with the host environment and could allow Web APIs to be called directly from WebAssembly.” ref
  • SIMD proposal for WASM (how related to multi-core?), the Web IDL bindings proposal (and its Interface Types) would allow WebAssembly to access the native web API’s (which allow operating on the DOM). → Any programming language (that could compile to WASM [1]) would be able to operate on the DOM! Languages that support multi-threading (of DOM operations, hence parts of GUI) will have an advantage. Golang? Rust? (check out Servo, a parallelized HTML layout engine in Rust!)
    • “Web IDL is an interface description language format for describing APIs that are intended to be implemented in web browsers.”
• WASM can be precompiled to JS on Node.js and run wherever Node.js can be run. Meaning no recompilation on client download. ref

Comments and challenges to the above assertions are very welcome.

One interesting response came from Ryan Carniato, creator of state-of-the-art JS rendering library SolidJS. He said (emphasis mine):

A good summary. I'm aware of these proposals but these things take years. So what I was getting at is I give it about equal chance that JavaScript to WASM compilation gets in a good place before those proposals get implemented. To be performant enough to push JavaScript further into the backend before it's practical to take WASM approaches mainstream in the browser.

So, the future remains to be seen: Will WASM make JS less relevant, or will WASM simply empower JS and make it more relevant, or will they forever remain complementary?

In any case, the future looks bright for those who love to have a variety of options (in languages and approaches).

What do you think the future of WASM and JS will look like, and why?

--- Update Feb 23, 2023:

I recommend hearing the JavaScript Jabber podcast episode The State of WASM (Dec 06, 2022). [1] They mention that compiling Garbage Collected (GC) languages (like Python, Ruby, etc.) to WASM is difficult, since WASM doesn't have it's own GC, which means you'd need to have a GC implementation in WASM, which your webapp would traditionally have to ship to the client (increasing the bundle size).

--- Update Feb 28, 2023:

A high level AI generated summary of the above notes:

In conclusion, WASM has the potential to augment JS by enabling node and JS to outsource tasks to other languages, and in the future, WASM may even be able to access the DOM directly through the native JS DOM API. While it may not outcompete JS in the near term, it is likely that it will in the future due to threads and SIMD. Compiling GC languages to WASM is currently difficult, however, as WASM does not have its own GC implementation. The future of WASM and JS remains to be seen, but it looks bright for those who love to have a variety of options.

--- Update May 24, 2023:

WASM GC was announced on the Google IO conference on May 10, 2023. Which will reuse the browser's own Garbage Collector, so that you don't have to ship a GC with your webapp.

That means you will be able to use Garbage Collected languages such as Java, Kotlin and Dart on WASM. It should open up for other Garbage Collected languages in the future, hopefully.