4 ms·

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

by azakai 3y ago

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.

LunaSea 3y ago
Really? I can't think of a mainstream (as in used daily) site that uses WASM. Do you have some in mind?
- hermanradtke 3y ago
  https://madewithwebassembly.com/ 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 3y ago
  Figma has been powered by WebAssembly for the past 7 years.
  - kamikazeturtles 3y ago
    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 3y ago
      They have a bunch of nice blogposts about that: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ 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).
- azakai 3y ago
  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 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.
- CharlesW 3y ago
  uBlock Origin first used Wasm in 2018: https://www.ghacks.net/2018/12/03/ublock-origin-performance-improvements-thanks-to-wasm-firefox-only-for-now/ https://www.ghacks.net/2018/12/03/ublock-origin-performance-...
- lxgr 3y ago
  Lichess and Chess.com use it for local position evaluation and playing against the computer (in analysis).
  - emporas 3y ago
    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.
dcode 3y ago
> 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.
- triyambakam 3y ago
  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 3y ago
    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)
- azakai 3y ago
  > 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.).
bsder 3y ago
> 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 3y ago
  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 3y ago
    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.
    - fabrice_d 3y ago
      > 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 3y ago
        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).

by azakai 3y ago

LunaSea 3y ago

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

hermanradtke 3y ago
https://madewithwebassembly.com/ 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 3y ago
Figma has been powered by WebAssembly for the past 7 years.
- kamikazeturtles 3y ago
  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 3y ago
    They have a bunch of nice blogposts about that: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ 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).
azakai 3y ago
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 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.
CharlesW 3y ago
uBlock Origin first used Wasm in 2018: https://www.ghacks.net/2018/12/03/ublock-origin-performance-improvements-thanks-to-wasm-firefox-only-for-now/ https://www.ghacks.net/2018/12/03/ublock-origin-performance-...
lxgr 3y ago
Lichess and Chess.com use it for local position evaluation and playing against the computer (in analysis).
- emporas 3y ago
  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.

dcode 3y ago

> 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.

triyambakam 3y ago
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 3y ago
  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)
azakai 3y ago
> 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.).

bsder 3y ago

> 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 3y ago
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 3y ago
  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.
  - fabrice_d 3y ago
    > 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 3y ago
      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).