[azakai]

This quote from the end of the article is good:

> With this in mind, maybe Wasm is mainstream. Spencer notes, for instance, that anyone who browses the web is likely to be interacting with WebAssembly on a daily basis.

I think that's correct. Non-Web usecases are a more complicated story (that the article focuses on), but the Web side is largely complete and successful, and that was the original purpose of Wasm. In that sense it's already succeeded.

[dcode]

> the Web side is largely complete and successful

Perhaps from a C++ perspective, say a monolith with kilobytes of bindings driving a canvas. Yet

> the original purpose of Wasm

includes, as per the charter, "and interoperate gracefully with JavaScript and the Web", which is far from complete and, thanks to WASI and the Component Model, hardly improving. I guess it will remain a mystery how WASI could basically replace something as obviously useful as WebIDL-bindings - that is, until someone figures out.

[azakai]

> Perhaps from a C++ perspective, say a monolith with kilobytes of bindings driving a canvas.

I get the desire for something more "elegant/clean" in this space, but JS is just very hard to beat on the bindings/glue side. I believe that's why approaches like WebIDL bindings did not turn out to be more efficient. I measured that on both code size and speed in Emscripten, for example, back in the day, and JS was good enough.

With WasmGC it is today possible to ship very small binaries, and the size of the bindings alongside them is generally not an issue, from what I hear from WasmGC-using toolchains like Java, Kotlin, and Dart. In fact they benefit a lot from the flexibility of those bindings, e.g. by being able to pull in random JS things (like strings support, RegExp, etc.).

[triyambakam]

Can you elaborate on why you think WASI and the Component Model is ruining that? I am only vaguely familiar with the state of WASM and squinting from this distance it seemed that WASI and the CM were meant to really improve a lot of problems. I'm not familiar with WebIDL bindings

[flohofwoe]

The WASM component model looks like it wants to free us from the "C ABI" (yes I know technically there's no such a thing) and give us a "high level language agnostic ABI", but when you take a closer look it's really just a hodgepodge of base types from the Rust stdlib in a trenchcoat, so it basically replaces the "C ABI" with something that's a bit friendlier for Rust coders to work with, but that's about it (at least that's the gist, of course there's a lot more than the ABI spec, but that's also a problem of the Component Model: it lacks focus)

[bsder]

> the Web side is largely complete and successful

Can WASM access the DOM? Or do you still have to go through a glacially slow Javascript export shim?

[robocat]

I thought it was the DOM API that was glacially slow?

Would WASM directly accessing the DOM be an improvement of more than say 5%

[marcosdumay]

The DOM has two different APIs, a batch and a piecewise ones. The batch one is incredibly optimized in all the browsers, while the piecewise one usually do not receive any attention at all.

Now, FFI the interface between WASM and JS is incredibly slow. That's by design. I guess the goal was to push every important API into WASM, and leave the FFI just for interfacing code, like on normal environments. People avoid problems with it by batching their data and interfacing as few times as possible, but just like on the JS DOM interface, this is a severe constrain on your code.

[flohofwoe]

Calling between WASM and JS really hasn't been slow in browsers since around 2018:

https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

It would be extremely surprising if calling overhead into JS to manipulate the DOM is noticeable in profiling instead of being dominated by the actual DOM manipulation (I have mainly experience with WebGL and WebGPU, where each call also goes through a JS shim, with a sometimes nontrivial amount of work happening in the JS shim, and the actual call overhead from WASM into JS is absolutely negligable compared to the overall cost, which is typically inside the WebGL and WebGPU implementation).

Also: if performance matters, don't use the DOM in the first place!

[fabrice_d]

> The DOM has two different APIs, a batch and a piecewise ones. The batch one is incredibly optimized in all the browsers, while the piecewise one usually do not receive any attention at all.

What are you talking about?

[bobbylarrybobby]

I'm going to go out on a limb and guess that they mean that if you want to modify the DOM with JS, you cannot batch your updates into an atomic transaction; every modification is applied immediately. However, presumably there is something, somewhere, that can collect modifications and apply them concurrently, because this would be such an insanely obvious optimization to miss for non-JS-driven updates to the DOM (such as initial page load).

[kevincox]

It isn't two APIs, but there is effectively some batching. The main thing to focus on is triggering layouts. Basically you want to do all of your reads together then all of your writes.

For example imagine we are trying to move one element to the location of another one. This code will be slow because the read of `leader.offsetTop` will need recalculate the layout to see if that write of `follower.style.left` changed the position of `leader`.

    let x = leader.offsetLeft;
    follower.style.left = `${x}px`;
    let y = leader.offsetTop;
    follower.style.top = `${y}px`;
    

However the following code is fast because it can read all of the values that were calculated during the last render (for the user to see) and doesn't trigger an intermediate relayouts.

    let x = leader.offsetLeft;
    let y = leader.offsetTop;
    follower.style.left = `${x}px`;
    follower.style.top = `${y}px`;

But I am not aware of any explicit batching UI.

[LunaSea]

Really? I can't think of a mainstream (as in used daily) site that uses WASM.

Do you have some in mind?

[azakai]

Sure, many major sites use it, such as Zoom, Google Sheets, and Photoshop. As the article mentions, you wouldn't know they are using Wasm under the hood unless you open the devtools and inspect the details.

Many more examples, such as those mentioned in this talk about Wasm usage in Google:

https://www.youtube.com/watch?v=2En8cj6xlv4

They mention Google Photos, Google Meet, Google Earth, TensorFlow.js, Ink, CanvasKit, Flutter, etc. And that is just inside Google - many other companies are using it, big and small, such as Figma, Unity, Adobe, etc.

[hermanradtke]

https://madewithwebassembly.com/

I see a few major sites and some major plugins. The definition of "mainstream (as in used daily) site" may differ between groups.

[callahad]

Figma has been powered by WebAssembly for the past 7 years.

[kamikazeturtles]

What parts of Figma though? Is it just used for cpu intensive operations like triangulation of svgs to render in webgl or is the site's core logic all done is wasm?

I'm sorry, I don't use Figma but I'm really curious about its tech stack

[azakai]

They have a bunch of nice blogposts about that:

https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

The main part of the app is in wasm, I believe (it's in C++ that they compile).

[lxgr]

Lichess and Chess.com use it for local position evaluation and playing against the computer (in analysis).

[emporas]

Yep, they compiled Stockfish to wasm. Now everyone has access to the best chess engine in the world, right there in the browser, no need to install anything. Really nifty.

[CharlesW]

uBlock Origin first used Wasm in 2018: https://www.ghacks.net/2018/12/03/ublock-origin-performance-...