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.

Comments

[Magne]

The future of WASI (WebAssembly System Interface), which is a set of standard API's for server-type stuff (files, networks, sockets, clocks, etc.).

WebAssembly Interface Types, is a language independent format for defining a set of functions and data types. File extension: .wit

WASM Component model - Sharing WebAssembly components on the server (using .wit) created in different languages that compile to WASM, so that they can work together.

The goal: A cross-language package ecosystem!

youtu.be/p9taQkF24Fs?t=2513

[Magne]

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 have to ship to the client (increasing the bundle size).

[Magne]

Towards a modern Web stack (with WASM) (Jan 2023) by Ian Hickson - docs.google.com/document/u/0/d/1pe...

[Magne]

Another perspective: The Future Web: Will Canvas Rendering Replace the DOM? (paywalled). Which references Google's decision (11. may 2021) to use HTML5 <canvas> for rendering instead of the DOM, for Google Docs, to: "improve performance and improve consistency in how content appears across different platforms". Which seems in line with their Flutter strategy of taking full control over rendering, to avoid platform constraints.

If the DOM is no longer a target, how would this affect WASM vs. JS?

• JS' benefit of native DOM access would be marginalised.
• Multi-threading of DOM operations per se would no longer be important. Would multi-threading be very beneficial when targeting something like HTML5 canvas or WebGL with web content? If so, would it mean that JS as a single-threaded language falls out of favor?

(Related: React rendering directly to WebGL? Sebastian Markbåge - DOM as a Second-class Citizen at react-europe 2015)

[Magne]

Some more notes on how Flutter will play into this:

Flutter vision:

• Google want to be platform-independent. Flutter was thus not concieved as an SDK for iOS and Android. It's an inherently cross-platform engine.
• Vision is "a portable toolkit wherever you need to paint pixels". ref
  • Chromebook
  • iPhone
  • Android
  • Raspberry Pi
  • Mac
  • Windows

Google wants Flutter to succeed because of their ChromeOS and Android replacement Fuchsia OS which uses Flutter for its UI.

Fuchsia doesn’t use the Linux kernel, but a new kernel Zircon (derived from Little Kernel, a real-time kernel for embedded devices. It uses event-driven programming and observers instead of unix-like signals, and don’t block the main thread. Resources are objects, not files, unlike Unix systems. It is presumably more modular than the Linux kernel. ref), which is designed “to run on anything from 32-bit or 64-bit ARM cores to 64-bit ppc processors” meaning “from embedded systems to smartphones, tablets, and personal computers”. ref Android is not a modular OS, while Fuchsia is. Android turned out too clunky to fit on IoT embedded systems. ref

Flutter to WASM on Web?

• “ Using a combination of DOM, Canvas, and WebAssembly [WASM], Flutter can provide a portable, high-quality, and performant user experience across modern browsers.” but Flutter can use HTML renderer or CanvasKit renderer: “Choose the html option if you are optimizing download size over performance on both desktop and mobile browsers. Choose the canvaskit option if you are prioritizing performance and pixel-perfect consistency on both desktop and mobile browsers.”

_But, isn't Flutter on web (HTML5 canvas) a threat to Google (relying on document indexing)? So would Google eventually kill it, or would they simply find a way of crawling the HTML-like widget trees that Flutter creates and renders to the canvas?

Similar to how Facebook have been envisioning bypassing the DOM.

What about programming styles? What is in vouge and what will be preferred in the future?

• Flutter will lean more towards OOP ref and ref
• React Native will lean more towards FP, with their pure function tendency.

Where does this lead to?

Facebook is developing Eye OS for their VR/AR initiatives, to be independent of Google's Android. ref and ref. See: React Native's Many Platform Vision.

What is interesting is that Microsoft (+ Facebook obviously) seems to be going for React Native as the cross-platform tool of choice: microsoft.github.io/react-native-w...

Whereas Google is going for Flutter.

And Apple has Swift/Objective-C, in their own iOS+macOS ecosystem. (Will they ever optimise for cross-platform? probably not, if history is any measure)

So will this cross-platform battle come down to a battle between Operating System manufacturers?

Google vs. Microsoft & Facebook (vs. Apple?) ...

What do you think?