We use WASM quite a bit for embedding a ton of Rust code with very company specific domain code into our web frontend. Pretty cool, because now your backend and frontend can share all kinds of logic without endless network calls.

But it’s safe to say that the interaction layer between the two is extremely painful. We have nicely modeled type-safe code in both the Rust and TypeScript world and an extremely janky layer in between. You need a lot of inherently slow and unsafe glue code to make anything work. Part is WASM related, part of it wasm-bindgen. What were they thinking?

I’ve read that WASM isn’t designed with this purpose in mind to go back and forth over the boundary often. That it fits the purpose more of heaving longer running compute in the background and bring over some chunk of data in the end. Why create a generic bytecode execution platform and limit the use case so much? Not everyone is building an in-browser crypto miner.

The whole WASM story is confusing to me.

It's not just the DOM, it's also all other APIs like WebGL2.

I ended up having to rewrite the entire interfacing layer of my mobile application (which used to be WebAssembly running in WebKit/Safari on iOS) because I was getting horrible performance losses each time I crossed that barrier. For graphics applications where you have to allocate and pass buffers or in general piping commands, you take a horrible hit. Firefox and Chrome on Windows/macOS/Linux did quite well, but Safari...

Everything has to pass the JavaScript barrier before it hits the browser. It's so annoying!

The web is a platform that has so much unrealized potential that is absolutely wasted.

Wasm is the perfect example of this - it has the potential to revolutionize web (and desktop GUI) development but it hasn't progressed beyond niche single threaded use cases in basically 10 years.

Is there any data on the performance cost of JS/WASM context switches? The way the architecture is described, it sounds as if the costs could be substantial, but the approaches described in the article basically hand them out like candy.

This would sort of defeat the point that WASM is supposed to be for the "performance critical" parts of the application only. It doesn't seem very useful if your business logic runs fast, but requires so many switching steps that all performance benefits are undone again.

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

Law of question marks on headlines holds here: no / never seems to be the answer.

Article l also discussed ref types, which do exist and do provide... Something. Some ability to at least refer to host objects. It's not clear what that enables or what it's limitstions are.

Definitely some feeling of being rug-pulled in the shift here. It felt like there was a plan for good integration, but fast forward half a decade+ and there's been so so much progress and integration but it's still so unclear how WebAssembly is going to alloy the web, seems like we have reams of generated glue code doing so much work to bridge systems.

Very happy that Dan at least checked in here, with a state of the wasm for web people type post. It's been years of waiting and wondering, and I've been keeping my own tabs somewhat through twists and turns but having some historical artifact, some point in time recap to go look at like this: it's really crucial for the health of a community to have some check-ins with the world, to let people know what to expect. Particularly for the web, wasm has really needed an update State of the Web WebAssmebly.

I wish I felt a little better though! Jco is amazing but running a js engine in wasm to be able to use wasm-components is gnarly as hell. Maybe by 2030 wasm & wasm-components will be doing well enough that browsers will finally rejoin the party & start implementing new.

I'm worried that wide use of WASM is going to reduce the amount of abilities extensions have. Currently a lot of websites are basically source-available by default due to JS.

I want DOM access from WASM, but I don't want WASM to have to rely on UTF-16 to do it (DOMString is a 16-bit encoding). We already have the js-string-builtins proposal which ties WASM a little closer to 16-bit string encodings and I'd rather not see any more moves in that direction. So I'd prefer to see an additional DOM interface of DOMString8 (8-bit encoding) before providing WASM access to DOM apis. But I suspect the interest in that development is low.

Disclaimer: I work on Jco, one of the user-facing Bytecode Alliance WASM JS ecosystem projects

Just a note, but there is burgeoning support for this in "modern" WebAssembly:

https://github.com/bytecodealliance/jco/tree/main/examples/c...

If raw WebIDL binding generation support isn't interesting enough:

https://github.com/bytecodealliance/jco/blob/main/packages/j...

https://github.com/bytecodealliance/jco/blob/main/packages/j...

https://github.com/bytecodealliance/jco/blob/main/packages/j...

Support is far from perfect, but we're moving towards a much more extensible and generic way to support interacting with the DOM from WebAssembly -- and we're doing it via the Component Model and WebAssembly Interface Types (WIT) (the "modern" in "modern" WebAssembly).

What's stopping us the most from being very effective in browsers is the still-experimental browser shim for components in Jco specifically. This honestly shouldn't be blocking us at this point but... It's just that no one has gotten around to improving and refactoring the bindings.

That said, the support for DOM stuff is ready now (you could use those WIT interfaces and build DOM manipulating programs in Rust or TinyGo or C/C++, for example).

P.S. If you're confused about what a "component" is or what "modern" WebAssembly means, start here:

https://component-model.bytecodealliance.org/design/why-comp...

If you want to dive deeper:

https://github.com/WebAssembly/component-model

I am confused by this. If WASM is a VM then why would it understand the DOM? To me it akin to asking "When will Arm get DOM support?" Seems like the answer is "When someone writes the code that runs on WASM that interacts with the DOM." Am I missing something? (not a web dev.)

I don't think I want WebAssembly to have DOM support.

Would it be nice? Yes. But.

Every added feature is a trade-off between need -vs- outlay, overhead, complexity & other drawbacks. In order to justify the latter things, that "need" must be significant enough. I'd like to have DOM, but I don't feel the need is significant.

Some thoughts on use-cases:

1. "Inactive" or "in-instance" DOM APIs for string parsing, document creation, in-memory node manipulation, serialisation: this is all possible today in WASM with libraries. Having it native might be cool but it's not going to be a significantly different experience. The benefits are marginal here.

2. "Live / active" or "in-main-thread" direct access APIs to manipulate rendered web documents from a WASM instance - this is where the implementation details get extremely complex & the security surface area starts to really widen. While the use-cases here might be a bit more magical than in (1), the trade-offs are much more severe. Even outside of security, the prospect of WASM code "accidently" triggering paints, or slow / blocking main thread code hooked on DOMMutation events is a potential nightmare. Trade-offs definitely not worth it here.

Besides, if you really want to achieve (2), writing an abstraction to link main-thread DOM APIs to WASM postMessage calls isn't a big lift & serves every reasonable use-case I can think of.

I have zero experience with anything wasm, just regular old DOM with typescript, but I wonder if this is the kind of problem that could be addressed the same way that phoenix liveview addesses frontend updates, by message passing only with diff changes, and delegate the Dom manipulation to what works, effective modelling the wasm runtime as an actor.

Why does WASM need to manipulate the DOM when JS already excels at that? Interfacing with JS was never really an issue; yes you do have to design reasonable module boundaries and understand how data is going to be shared. That just leads to simpler / stronger program design.

If you're writing a DOM UI heavy app, use JavaScript. Many WASM apps, like games, have no interest in the DOM. It's just more spec bloat.

Actually my journey was quite similar. I started to build a bindings and web components framework in Pure Go so that I can build user interfaces with webview/webview.

My apps just go:embed all their assets and spawn a local webview as their UI, which is quite nice because client and server use the same schemas and same validations for e.g. web forms and the fetch/REST APIs.

Server-side-rendered components are implemented using a web components graph whose components can be String()ified into HTML.

It's a bit Experimental though, and the API in the components graph might change in the future:

https://github.com/cookiengineer/gooey

Tangent: ACM queue this months seems to be dedicated to Wasm. Nice!

https://queue.acm.org/issuedetail.cfm?issue=3747201

Blame browsers.

Things like QT and browsers became popular because people realize they could short circuit OS vendors asking developer to be loyal to them. The glue won.

But QT and browsers and JS are just hotfixes, they're not sound technologies, they're just glue.

> Wasm includes various JavaScript APIs that allow compiler-generated glue code

One of the reasons I’m interested in wasm is to get away from the haphazardly evolved JS ecosystem…

Has anybody written a nice DOM wrapper for C++/Rust? So you can do everything from the comforts of the C++/Rust application? The API whould match JavaScript APIs as much as possible.

I am adding a WASI runtime (0.1 and 0.2) in https://exaequos.com, an OS running in the web browser. What would be a good DOM api ?

Interop with JS APIs is a requirement. Therefore, glue code is a requirement. If we’re not going to get direct access to the DOM, can we at least get the ability to just list the JS functions that our wasm will call? Of course the list will be bundled with (compiled into) the wasm blob, and whether it’s literally a text list or something like a registration call naming those JS functions, I am agnostic about. Everyone having to write all their own glue[*] is just nuts at this point.

[*]Yeah, the toolchains help solve this a bit, but it still makes me ship JS and wasm side-by-side.

    (module
        ...
        (import "env" "foo" (func (;0;) (type 1)))
        (import "env" "bar" (func (;1;) (type 2)))
        ...
    )

At this point, why not implement DOM inside WebAssembly? The end of DOM compatibility issues ...

i miss the times where computers where used to solve problem. Nowerdays people MAKE there problems themself by layering thousands of apis over each other and calling back and forth milions of times. no wonder computer are not getting faster.

I've been reading about this for a while. Will it. Won't it.

Does anybody know why is it such a big problem to add dom access to wasm?

In worst case, we should have a second option to Js (which is not typescript - typescript is just a lipstick on a pig). If wasm is not it, why not something different? Having dart in would be great.

I think this article is written in a very confusing way. I think I would have written it this way.

When writing most non-web software, you can usually write it easily in a high-level language (with a rich standard library and garbage collection), but you can get better performance (with more effort) by writing your code in a lower-level language.

WASM seems like an opportunity to get better performance by rewriting JavaScript web apps in lower-level languages like C or Rust, but it doesn't work that way, because of standardization.

Today, the web's core DOM APIs are defined in standards committees as inherently JavaScript APIs, in the form of WebIDL documents. https://developer.mozilla.org/en-US/docs/Glossary/WebIDL

When defining standardized APIs in WebIDL, WebIDL assumes that you can use JavaScript strings, JavaScript objects + properties, JavaScript Exceptions, JavaScript Promises, JavaScript garbage collection, and on and on and on. Almost all of the WebIDL specification is about the dozens of types that it assumes the platform already provides. https://webidl.spec.whatwg.org/

WASM doesn't have any of those things.

No one has ever standardized a DOM API for low-level languages. You'd need to start by standardizing a new "low-level API" for DOM access, and presumably a new low-level WebIDL to define those standards.

Designing the web by committee makes it hard to add/change stuff in browsers. You have to get Apple, Google, Microsoft, and Mozilla to agree on literally everything. (Defining WebIDL itself has taken decades!)

It can be hard to even get agreement from browser vendors to discuss the same topic, to even just get them to read your proposed standards document and to say "no, we won't implement it like this, because..." You have to convince them that the standard you're proposing is one of their top priorities. (And before you can do that, you have to convince them to pay attention to you at all.)

So, someone would have to persuade all of the browser vendors that one of their top priorities should be to invent a new way to standardize DOM APIs and begin the process of standardizing DOM access on top of a lower-level IDL.

Today, the browser vendors aren't convinced that this is worth their time. As the article says:

> For now, web folks don't seem to be sold on the urgency of this very large project. There is no active work by browser vendors in this direction.

And that's why you can't get top-notch performance by rewriting your web app in Rust. You can rewrite your web app in Rust, and it can access JS APIs, but when touching the DOM APIs, Rust has to interop with JS. Rust's interop with JS is no faster than JS itself (and it's often slower, because it requires added glue code, translating between JS and WASM).

As a result, if you're writing a web app, you mostly have to do it in JS. If you have some very CPU-intensive code, you can write that in WASM and slowly copy the result of your computation to JS, as long as you don't cross the boundary between WASM and JS too often.

Alternately, if you have existing code in non-JS languages, you can port it to web via WASM, but it'll probably run slower that way; the best performance improvement you can do is to rewrite it in JS!

The fact that this needs to be explained with mentions of pointers and data alignment and garbage collection tells me that the decisions that the web standards committees make continue to be just completely disconnected from anything sane.

maybe my read is wrong, but everything i look at today just screams to me that the web is extremely poorly designed; everything about it is simply wrong.

DOM is so dynamic, any integration with DOM will look no different than the way we do it now through JS. JS is built to work naturally with DOM.

Maybe we should stop overdesigning things and keep it simple. WASM needs more tooling around primitive types, threading, and possibly a more flexible memory layout than what we have now.

Emscripten has a handy tool called "Embind" for binding JavaScript/TypeScript and C/C++/whatever code. It's underappreciated and not well documented all in one place, but here is a soup-to-nuts summary.

Emscripten + Embind allow you to subclass and implement C++ interfaces in TypeScript, and easily call back and forth, even pass typed function pointers back and forth, using them to call C++ from TypeScript and TypeScript from C++!

Embind: https://emscripten.org/docs/porting/connecting_cpp_and_javas...

Interacting with Code: https://emscripten.org/docs/porting/connecting_cpp_and_javas...

Embind's bind.cpp plumbing: https://github.com/emscripten-core/emscripten/blob/main/syst...

C Emscripten macros (like EM_ASM_): https://livebook.manning.com/book/webassembly-in-action/c-em...

Emscripten’s embind: https://web.dev/articles/embind

I'm using it for the WASM version of Micropolis (open source SimCity). The idea is to be able to cleanly separate the C++ simulator from the JS/HTML/WebGL user interface, and also make plugin zones and robots (like the monster or tornado or train) by subclassing C++ interface and classes in type safe TypeScript!

emscripten.cpp binds the C++ classes and interfaces and structs to JavaScript using the magic plumbing in "#include <emscripten/bind.h>".

There is an art to coming up with an elegant interface at the right level of granularity that passes parameters efficiently (using zero-copy shared memory when possible, i.e. C++ SimCity Tiles <=> JS WebGL Buffers for the shader that draws the tiles) -- see the comments in the file about that):

emscripten.cpp: https://github.com/SimHacker/MicropolisCore/blob/main/Microp...

  /** 
   * @file emscripten.cpp
   * @brief Emscripten bindings for Micropolis game engine.
   *
   * This file contains Emscripten bindings that allow the Micropolis
   * (open-source version of SimCity) game engine to be used in a web
   * environment. It utilizes Emscripten's Embind feature to expose C++
   * classes, functions, enums, and data structures to JavaScript,
   * enabling the Micropolis game engine to be controlled and interacted
   * with through a web interface. This includes key functionalities
   * such as simulation control, game state management, map
   * manipulation, and event handling. The binding includes only
   * essential elements for gameplay, omitting low-level rendering and
   * platform-specific code.
   */
  [...]
  ////////////////////////////////////////////////////////////////////////
  // This file uses emscripten's embind to bind C++ classes,
  // C structures, functions, enums, and contents into JavaScript,
  // so you can even subclass C++ classes in JavaScript,
  // for implementing plugins and user interfaces.
  //
  // Wrapping the entire Micropolis class from the Micropolis (open-source
  // version of SimCity) code into Emscripten for JavaScript access is a
  // large and complex task, mainly due to the size and complexity of the
  // class. The class encompasses almost every aspect of the simulation,
  // including map generation, simulation logic, user interface
  // interactions, and more.
  [...]
    class_<Callback>("Callback")
        .function("autoGoto", &Callback::autoGoto, allow_raw_pointers())
  [...]

Here's the WebGL tile renderer that draws the tiles directly out of a Uint16Array pointing into WASM memory:

https://github.com/SimHacker/MicropolisCore/blob/main/microp...

The corresponding C++ source and header and TypeScript files define the callback interface and plumbing:

callback.h defines the abstract Callback interface, as well as a ConsoleCallback interface that just logs to the JS console, for debugging:

callback.h: https://github.com/SimHacker/MicropolisCore/blob/main/Microp...

  /** 
   * @file callback.h
   * @brief Interface for callbacks in the Micropolis game engine.
   *
   * This file defines the Callback class, which serves as an interface
   * for various callbacks used in the Micropolis game engine. These
   * callbacks cover a wide range of functionalities including UI
   * updates, game state changes, sound effects, simulation events, and
   * more. The methods in this class are virtual and intended to be
   * implemented by the game's frontend to interact with the user
   * interface and handle game events.
   */

  class Callback {

  public:

      virtual ~Callback() {}
      virtual void autoGoto(Micropolis *micropolis, emscripten::val callbackVal, int x, int y, std::string message) = 0;
      [...]

callback.cpp implements just the concrete ConsoleCallback interface in C++ with "EM_ASM_" glue to call out to JavaScript to simply log the parameters of each call:

callback.cpp: https://github.com/SimHacker/MicropolisCore/blob/main/Microp...

  /** 
   * @file callback.cpp
   * @brief Implementation of the Callback interface for Micropolis game
   * engine.
   *
   * This file provides the implementation of the Callback class defined
   * in callback.h. It includes a series of methods that are called by
   * the Micropolis game engine to interact with the user interface.
   * These methods include functionalities like logging actions,
   * updating game states, and responding to user actions. The use of
   * EM_ASM macros indicates direct interaction with JavaScript, typical
   * in a web environment using Emscripten.
   */

js_callback.h contains an implementation of the Callback interface that caches a "emscripten::val jsCallback" (an enscripten value reference to a JS object that implements the interface), and uses jsCallback.call to make calls to JavaScript:

js_callback.h: https://github.com/SimHacker/MicropolisCore/blob/main/Microp...

  #include <emscripten/val.h>
  #include "callback.h"

  class JSCallback : public Callback {
  public:
      explicit JSCallback(emscripten::val jsCallback)
          : Callback(), jsCallback(jsCallback) {}

      // Implement all pure virtual functions from Callback
      void autoGoto(Micropolis *micropolis, emscripten::val callbackVal, int x, int y, std::string message) override {
          jsCallback.call<void>("autoGoto", emscripten::val(micropolis), callbackVal, x, y, message);
      }

      [...]

  private:
      emscripten::val jsCallback;
  };

Then emscripten/embind generates a TypeScript file that defines the JS side of things:

micropolisengine.d.ts: https://github.com/SimHacker/MicropolisCore/blob/main/microp...

  // TypeScript bindings for emscripten-generated code.  Automatically generated at compile time.
  [...]
  export interface Callback {
    autoGoto(_0: Micropolis, _1: any, _2: number, _3: number, _4: EmbindString): void;
  [...]
  export type MainModule = WasmModule & typeof RuntimeExports & EmbindModule;
  export default function MainModuleFactory (options?: unknown): Promise<MainModule>;

Then you can import that TypeScript interface (using a weird "<reference path=" thing I don't quite understand but is necessary), and implement it in nice clean safe TypeScript:

https://github.com/SimHacker/MicropolisCore/blob/main/microp...

  /// <reference path="../types/micropolisengine.d.ts" />

  import type { Micropolis, JSCallback } from '../types/micropolisengine.d.js';

  // Micropolis Callback Interface Implementation

  export class MicropolisCallbackLog implements JSCallback {

      verbose: boolean = false;

      autoGoto(micropolis: Micropolis, callbackVal: any, x: number, y: number, message: string): void {
          console.log('MicropolisCallbackLog: autoGoto:', 'x:', x, 'y:', y, 'message:', message);
      }

It's all nice and type safe, and Doxygen will even generate documentation for you:

https://micropolisweb.com/doc/classJSCallback.html

And it even works, and it's pretty fast! (Type "9" to go super fast, but for the love of god DO NOT PRESS THE SPACE BAR!!!)

https://micropolisweb.com

[flagged]

This is one of those self-taught versus college educated subjects. See this for some background https://news.ycombinator.com/item?id=44599228

This subject is interesting because your typical college educated developer HATES the DOM with extreme passion, because it’s entirely outside their area of comfort. The typical college educated developer is typically educated to program in something like Java, C#, or C++ and is how the world is supposed to work. The DOM doesn’t work like that. It’s a graph of nodes in the form of a tree model, and many developers find that to be scary shit. That’s why we have things like jQuery, Angular, and React.

These college educated developers also hate JavaScript for the same reasons. It doesn’t behave like Java. So for many developers the only value of WASM is as JavaScript replacement. WASM was never intended or positioned to be a JavaScript replacement so it doesn’t get used very often.

Think about how bloated and slow the web could become if WASM were a JavaScript replacement. Users would have to wait on all the run time and dependencies to download into the WASM sandbox and then open like a desktop application, but then all that would get wrapped in something like Angular or React because the DOM is still scary.