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.
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.).
Do you have some in mind?
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.
I'm sorry, I don't use Figma but I'm really curious about its tech stack
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).
I see a few major sites and some major plugins. The definition of "mainstream (as in used daily) site" may differ between groups.
Can WASM access the DOM? Or do you still have to go through a glacially slow Javascript export shim?
Would WASM directly accessing the DOM be an improvement of more than say 5%
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.
What are you talking about?
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`;
let x = leader.offsetLeft;
let y = leader.offsetTop;
follower.style.left = `${x}px`;
follower.style.top = `${y}px`;
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!
> 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.