When Is WebAssembly Going to Get DOM Support?

I wonder how better DOM support would help a rust web application frontend framework like Leptos (https://leptos.dev)? Maybe a smaller WASM payload?

All of that exists at a way higher level. It's like saying ELF binaries don't provide good i18n or a11y. I don't even know how to interpret that.

I don’t know, I feel myself shifting the goalposts here, but at the same time, I don’t feel I’m unjustified in doing that. You’re probably not going to complain that the list of JVMs you linked is incomplete, even though there are probably small-scale JVMs in SIM cards and other such minuscule environments that are not listed there, and those could easily be something entirely unique that was written by a couple of guys in a room in 1997 and last had a feature added to it in 2000.

So I can’t help observing the non-obsolete JVMs not targeting an embedded usecase (and thus capable of supporting the kind of tools you’re referring to) are all either research projects or OpenJDK-based (or both). Harmony is dead. GCJ is dead. (Does Dalvik count?..) Oracle has already perpetrated half of a rugpull on OpenJDK and mostly murdered the JCP, and that ratchet only ever goes in one direction. And the tooling of the kind you describe is mostly sold by a handful of companies for a handful of notable languages, none of which were born outside the JVM context: Kotlin is the last entrant there, and it is very good, but the tooling is also very distinctly a single-vendor thing to the point that Google didn’t roll their own. (Both Clojure and Scala are lovely, but I don’t think they’re on the same side of notable as Java or Kotlin. Groovy still exists.) Jython was almost the last holdout for targeting the JVM, and it’s also effectively dead. JRuby is... surprisingly alive? But I don’t believe it has tooling worth a damn.

I guess what I want to say is, for a very long time—though not for the entirety of its history—it’s been an ecosystem centered on Java and not really on the JVM. Microsoft’s CLR actually made a fair attempt at, let’s say, multilingualism for significantly longer, but after the DLR flopped that was mostly the end of that. And, of course, instead of a Java-centric ecosystem it was from the start a Microsoft-centric ecosystem, and after the stunts they’ve pulled (most recently) with their VSCode extensions and language servers I don’t trust any development tool Microsoft releases to continue to exist in any given form for any given duration.

So I don’t think there’s really anything mature that would be VM-centric in the way that Wasm is, that would furthermore not go up in smoke if a single vendor decided to pull out. That’s not to say I think Wasm is the pinnacle of computing–I think it’s pretty wasteful, actually, and annoyingly restrictive in what languages it can support. I just don’t think it really retreads the paths of any of the (two) existing prominent VM-based platforms.

> "Ah, but each container will run it's own separate runtime process." Sure, but the most valuable resource that probably wastes is a PID (and however many TIDs). Processes exec'ing the same program will share a .text and .rodata sections and the .data and .bss segments are COW'ed.

In terms of memory footprint, I can allow that the OS may be smart enough to share a lot of the exec'ed process if it's run multiple times. With Go and Rust and other statically compiled programs, that's going to scale to the number of instances of a service. With Node you might scale more, but then you need to start dynamically loading app code and that won't be shared.

With wasm hosts, you can just ship your app code, and ask the wasm host to provide libraries to you. So you can have vastly more memory sharing. Wasm allows a lot of what you term p_i to be shifted into k through this sharing.

But there's so many other reasons to have a a shared runtime rather than many processes.

Context switching can be a huge cost, one that a wasm host can potentially avoid as it switches across different app workloads. Folks see similar wins from v8 isolates, which for example CloudFlare has used on their worker platform to allow them to scale up to a massive number of ultra-light worker.

> Even for deploying wasm containers. Maybe there are certain technical reasons why they needed an alternate "container" runtime (wasi) to run wasm workloads with CRI orchestration, but size is not a legitimate reason. If you made a standard container image with the wasm runtime and all wasm applications simply base off that image and add the code, the wasm runtime will be shared between them, and only the code will be unique

The above talks to some of the technical reasons why an alternate runtime enables such leaps and bounds versus the container world. Memory size is absolutely the core reason; that you can fit lots of tiny micro-processes on a wasm host, and have them all sharing the same set of libraries. Disk size is a win for the same reason, that containers don't need to bundle their dependencies, just ask for them. There's a 2022 post talking about containers, isolates, and wasm, talking more to all this arch: https://notes.crmarsh.com/isolates-microvms-and-webassembly

Thanks for sharing your thoughts -- I think I have a clearer grasp of what you were getting at now.

> Honestly, I can't believe you're asking me this! You're so far in the weeds of the WASM component model that you have no idea what the problem is. It's really silly to ask what the "most important blockers" are, as if it's a list of bugs that can be fixed.

This is a pretty unproductive way to converse -- I asked because I wanted to know what you thought the blockers were. Problems can be broken down into smaller ones, and getting on the same page with regards to the problem is key to producing better software and meeting user needs.

We can't solve a problem if we can't enumerate it's pieces, and what people want can be varied.

> Today, if you take a UI-focused DOM-heavy web app that makes lots and lots of DOM API calls (i.e. most JS web apps ever written) and try to rewrite it in Rust, you'll have to cross the boundary between JS and WASM over and over again, every time you use a DOM API. Every time you add/remove/update an element, or its styles, or handle a click event, you'll cross the boundary.

At present, you must cross two boundaries. One out of WASM and one in JS into the engine.

> And it's not just strings. All JS objects that you need to do actual work with have to be serialized/deserialized in this way, because WASM only knows about bytes, arrays, and opaque pointers. DOM elements/attributes, DOM style properties, DOM events (click events, keyboard events, etc.), all of them get slow when you transfer them in and out of WASM land, even with reference types, because of serialization/deserialization.

> WASM interface types will make it easier to call JS from WASM, but as long as you're still calling JS in the end, rewriting in Rust will never make a DOM-heavy web app faster than writing it in JS.

This is untrue, Wasm interfcace types make it easier to call any language from Wasm. This includes the languages that browsers are written in, namely C++, Rust, etc. This opens a path to optimization and possible direct application of the APIs that JS uses today.

Also as a side note -- increased performance of DOM operations is not the only goal worth pursuing. For example, performance parity with JS is also a worthy goal, because holistically Wasm as a compute option has other benefits.

> The only fix, as Daniel's article explains, would be to standardize a low-level DOM API, one that didn't assume that you can use JS strings, objects+properties, exceptions, promises, etc. This would be an unimaginably large standardization project. > > You couldn't use WebIDL at all; you'd need to start by defining a new "low-level WebIDL." Then, you'd start standardizing the entire DOM API, all over again (or at least the most important parts) in low-level WebIDL, and then browser vendors could start implementing the low-level DOM API.

Introducing a completely new low level DOM API is ideal, but is naive in practice. WebIDL is the lingua franca for browser integration at this point, for the one language that actually has such support.

Standards are hard to create (especially from scratch), we cannot control how fast browsers implement or the priorities of browser companies.

> Then WASM could start calling that API directly. And maybe then you could rewrite web apps in Rust and have them get faster.

Embedders of WebAssembly components (i.e. browser engines written in C++/Rust/etc) may choose to fulfill the imports of WebAssembly components however they'd like. It is indeed possible that a browser engine, upon instantiating a WebAssembly component that does DOM work, fulfills the WebIDL contract with more direct bindings to the underlying operations.

There will always be at least one hop across a boundary -- WebAssembly. That said, it is possible for that one hop to be optimized by embedding engines.

For any such optimization to even be possible (with or without the component model), standards bodies and browser vendors must agree on what the interface they are about to speak is. They have already agreed on WebIDL, so porting that is a good place to start independent of whether creating a completely new standard is feasible.

> So, what's the most important blocker? (gesture toward the universe) All of it??

Concretely, what needs to be optimized is DOM calls. They are not impossible, they are just inefficient at present. That is a problem that can be worked on, and I don't think it's productive to say "all of it". There are many discrete steps that need to be accomplished to get to cross-browser consistently performant DOM support for components, and it's reductive to assume there is only one step to be done/that it all gets done at once.

A realistic path to optimization of any more performant interaction with underlying browser engine primitives is working with the interfaces they already have. WebIDL to WIT support (i.e. cross browser and cross platform as it's WebAssembly native) is a step in that direction, and as such is forward progress. If we can't agree there, we'll have to agree to disagree.

At this point it's a matter of working with browser vendors on their embeddings, and getting whatever bindings we agree on to be performant inside the relevant browser engine.