[csjh]

Mass adoption in what way? What benefit does the average CRUD web app gain from using some form of WebAssembly?

[anoopelias]

Not sure if WASM is there yet, but maybe the crud app can be built using a programming language that the developer prefers? Like Java, C#, Go, Rust, C++, whatever instead of JavaScript/TypeScript?

[billti]

Yeah, we took a bet that writing our compiler, simulator, etc. in Rust and architecting correctly so it could compile to native and WASM would let us run native and in the browser too, and we’re pretty thrilled with how it turned out.

We just shipped 1.0, but this slightly older blog post goes into the architecture a bit more: https://devblogs.microsoft.com/qsharp/introducing-the-azure-...

[dist1ll]

I'm currently taking the same route with my compiler. It's written with extreme efficiency in mind, so I'm planning to expose a client-side WASM binary on the main site, that will let you interactively explore the language with low latency.

[lioeters]

This is a great use case of WASM, I think. Language compilers/interpreters/runtimes to be compiled to WASM so they can run on the web, enabling interactive code blocks, playgrounds, or integration with web-based code editor and IDE. That lowers the barrier to entry, so a beginner (or seasoned user) can simply visit a web page and start playing with running code - instead of having to install anything on their local machine.

[ledgerdev]

Have you considered an open source the parser/compiler framework that targets wasm? I suspect that dsl's and tiny languages compiled directly to wasm could be valuable.

[thrdbndndn]

To incorporate something currently is only available in "native" program form is what I am thinking; like ffmpeg example above.

[azakai]

I think most web pages do not need such features. WebAssembly has seen lots of adoption on the websites that do, like Figma and Photoshop for design, Zoom and Meet for interactive video, Unity for games, etc. etc. But most web pages are just text, and that's fine.

Wasm was never intended to be used on every web page, just like the Video element wasn't.

[ReleaseCandidat]

Yes, but WASM does not solve a problém which (many) people have. Of course there are some applications, like online image or video editors.

[pjmlp]

Which could have been done with WebAudio and WebGL/WebGPU as well, without the pain of dealing with WebAssembly tooling.

[paulgb]

Surely you mean WebCodecs rather than WebGL/WebGPU? AFAIK no encoding primitives are exposed by WebGL/WebGPU.

The advantage of shipping an encoder in WebAssembly for is that you don’t have to rely on the browser supporting the specific codec you want. e.g. Safari and Firefox don’t yet support WebCodecs at all, but do support WebAssembly.

[pjmlp]

I really mean WebGL/WebGPU and using shaders instead of C and C++, while being GPU accelerated.

For a small taste,

"Meet Leon - superfast GPU-accelerated (WebGL) mpeg1-like video decoder in JavaScript"

https://www.easy-bits.com/mpeg1video-decoder-webgl-gpu

See mpeg1video-decoder-webgl.js on developer tools.

[paulgb]

Oh interesting! I found this as well: https://jsmpeg.com/

I didn’t realize enough of the work in decoding mpeg was paralellizable enough to do on the GPU, let alone in the constrained world of WebGL, but apparently it is.

[duped]

Do you mean those features added to WebAudio or that you could use WebAudio to implement those features, because the latter is not really true

[adrusi]

it's maybe negligible compared to the code-size bloat of web applications, but delivering large libraries over the network with only limited caching is less than ideal