[shevy-java]

Will WebAssembly ever achieve a real breakthrough? It's been almost 10 years since it came around. HTML, CSS and JavaScript were a breakthrough back in the days. WebAssembly still is not right now; only very few folks or companies use it.

[CGamesPlay]

I think its killer use case is actually embedded in non-web places. Tree Sitter parsers require arbitrary programs to be able to parse arbitrary languages. WebAssembly is a natural way to achieve that: write your parser in any language, compile to WebAssembly, use that result in any supported editor. You get sandboxed execution and arbitrary compute.

It has to compete with more domain-adapted use cases though. Does WASM make more sense than eBPF for packet filtering? It doesn't seem to make more sense than JavaScript for making websites. Maybe it makes more sense for deploying edge services (which IIUC is the main use case for WASI).

[wongarsu]

Plugin architectures are a niche where WASM really shines. Before WASM most plugins were either high performance (loading dynamic libraries) or sandboxed and safe for untrusted plugins (LUA etc). WASM allows you to have your cake and eat it to. You pay with a bit of complexity, but it's in a great and somewhat unique place in the tradeoff space

[modulovalue]

It's already a breakthrough in my opinion.

Many things are possible that weren't possible before. For example, I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web: https://github.com/modulovalue/dart-live it supports hot reload and many other cool features. It runs essentially everywhere and it's a very bare proof of concept for a fully integrated programming development system.

The problem is that things just take time if you have to coordinate across a bunch of languages and teams while trying to make everyone happy.

To give you a sense of what else is coming: the wasm ecosystem is moving towards supporting a component model. Eventually you'll be able to import any piece of code from any programming language that supports it. Wasm interface types will make that possible.

[Rochus]

> I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web

Is this really a representative use-case of WASM/WASI? Would'n it be much better to compile Dart to WASM (the Dart SDK even supports "dart compile wasm")?

[throawayonthe]

this is a confusing question; why would it be much better to e.g. compile a C program for x86 linux musl but not the C compiler?

[Rochus]

Your analogy doesn't quite hold. The primary use case of a compilation target is to compile programs, not the compiler itself.

With Dart specifically, "dart compile wasm" already exists precisely for that purpose. Compiling the entire Dart VM (a multi-hundred-thousand-line C++ codebase) to Wasm and then running Dart inside that is a clever in-browser IDE trick, but it's heavy, indirect, and not what Wasm/WASI was designed to showcase. It also sidesteps WasmGC, which is exactly the kind of Wasm evolution that makes Dart-to-Wasm compelling.

[swiftcoder]

I think I've seen you comment this on every recent WASM post, and I'm really wondering what you think breakthrough success looks like for a low-level technology like WASM?

Do you expect everyone to hand-code their websites in WASM? Do you expect every webapp be cross-compiled to WASM?

From where I'm standing, WASM is extremely successful in its specific niches: in enabling islands of high-performance in otherwise web-based software, and in sandboxing plugins to native apps/servers.

[callahad]

It's a silent technology, but I'd argue it has broken through in that most of us already use it daily without knowing. Figma, Google Sheets, Disney+, Prime Video, and much more all have WebAssembly somewhere in their stack.

[kettlecorn]

WebAssembly is used in all sorts of ways.

It's used heavily by major web apps like Figma, it's used to run non-Javascript languages on Cloudflare Workers, many compute-heavy web libraries rely on Wasm modules, many web games rely on Wasm, it's used for safe plugins in some native apps like Microsoft Flight Simulator, amongst other use cases.

[OtomotO]

WASI stands for WebAssembly System Interface.

It has little to do with the webassembly in the browser.

I use it to extend a native application, for example. No browser in sight at all.

[__s]

It has, but its usually just an optimization, so goes unnoticed

[grufkork]

I mean, it’s another tool. It doesn’t really make an entirely new kind of web app possible, but it’s useful for some specific compute-heavy tasks (with limitations like JS<->WASM being slow). It’s also useful for running not-JS in the browser; I’m building a lighting console with a web UI distributed over multiple devices, and being able to use the exact same structs/representation and algorithms on server and client is pretty neat. It’s like Node, but in reverse! But none of this is cause for paradigm shift, so I don’t think seeing a ”breakthrough” really is relevant.

[Dwedit]

WebAssembly doesn't beat JavaScript in performance, and that is embarrassing.

[throawayonthe]

it is faster, but there is unacceptable loss when passing data to/from js, definitely an area needing improvement (or having to do it less)

https://hacks.mozilla.org/2026/02/making-webassembly-a-first...

[Dwedit]

Just allowing more than one arraybuffer could go a long way to help with performance. One array buffer for the wasm memory space, then an arraybuffer for each input or output argument.

[tekne]

Wasm multiple memories is a thing now

[kettlecorn]

That's not accurate. I Googled for a recent performance benchmark and found this which indicates Wasm offers a notable performance gain: https://medium.com/@hashbyt/webassembly-vs-javascript-perfor...

[Dwedit]

My task in question was a number crunching task, basically doing multiply-and-add for 336-bit integers. I wrote a JS version, and a C version compiled into WASM by using Zig. You'd think that WebAssembly would trounce JS here, but it actually didn't.

The JS code had been written carefully to avoid allocations, and also avoiding the built-in JavaScript BigInt. I rolled my own BigInt instead using an array of numbers. Each number, despite being a double, was basically a 48-bit integer. Long multiplication requires splitting a 48-bit integer into two 24-bit integers so an intermediate multiplication result will fit in 48 bits.

The C version used 32x32=64-bit integer math. (Would have been nice if WASM had supported 64x64=128-bit multiplication)

Even with the overhead of using doubles instead of integers, the JavaScript and C versions ran at nearly the same speed. I think the C version was slightly faster, but not significantly. The C version took a lot longer to load, as it had to instantiate a Webassembly object, and had to run glue code to copy things in and out of Webassembly memory.

[jason_oster]

> and had to run glue code to copy things in and out of Webassembly memory.

Not surprising. The FFI boundary is always a bottleneck. If you can eliminate it, you will see where the WASM JIT shines. You have far more control over mechanical sympathy with C/WASM than JavaScript (though far from perfect).

Also, consider publishing your findings and ask for reviews for optimization opportunities.

[lioeters]

You said the exact same thing a couple days ago. You don't know what you don't know.

WebAssembly has been a great success thanks to its excellent initial design.

[artemonster]

for me its undebuggability.

-"hey, look at our C Rust FORTRAN to WASM translator, blahblah"

-"uhm, cool, how do I debug it?"

-"yeah...about that...you cant!"

[phickey]

Wasmtime implements a remote debugging server, so that you can debug guest programs with a recent build of LLDB. Set breakpoints based on the source language symbols, single-step through wasm opcodes, anything you'd expect: https://docs.wasmtime.dev/examples-debugging-guest.html

[artemonster]

still useless. I had an idea to offload parts of my game core into wasm leaving only UI in the browser - I abandoned that idea when there was absolutely zero possibility for me to debug in browser what is wrong with my core. i just rewrote everything to TS (from rust)

[tdhz77]

Why can’t you?

[artemonster]

how can you? its running wasm in a browser, how do you see original C/Rust code and or variables

[fsloth]

This! The only way to get to a stable system at least with c/c++ source, where you can hunt bugs, is to have a fairly large unit test coverage. When something fails - add that as test case; run ctest - pray that this is discoverable with tests.

So wasm is a really strange compilation target for systems programming languages.

I mean there _are_ ways to debug it in a browser but they sort of suck.

[bearjaws]

I'm building a game where you learn to program golang or python and it all runs in webassembly, this way any student chromebook can just pick up and go.

That feels pretty revolutionary, no need to setup your local system to get core concepts.

Even have plans to use postgres in WASM (pglite), and I know a few real time apps use sqlite in WASM.