Web assembly is generally an optimization, not an app alternative. Think of it the way you would the C bindings Node.js has. If you've got a compute-heavy code path, writing it in C (or Rust etc) and shipping it as web assembly could be a dramatic perf improvement, but there's not really a substantive benefit to writing your entire app with it.

> but there's not really a substantive benefit to writing your entire app with it.

Amendment: Perhaps it's debatable what "substantive benefit" would be, but writing the whole app in it is a huge benefit if you really want to do that. That is to say, for years people wanted to write Web UI stuff in various languages, this also allows for that.

So while the concrete performance boost may not be meaningful in writing an entire web app in C, Rust, Go, Python or w/e - to the developer happiness the boost may be huge for those devs that want it.

Well, you still can't do that—WASM doesn't have DOM bindings, you'd still have to ship out to JS. I believe that's a goal, so yes eventually that could be a benefit, but not at the moment.

Fwiw, you can - just perhaps with not pure WASM and perf.

My next app I'm planning on using a Rust WASM DOM framework, and I know there are some in Go as well. This is primarily for developer UX.

DOM bindings are kind of irrelevant when one has WebGL.

One example among many ramping up

https://platform.uno/

Rendering UIs in webgl is fairly user-hostile. No accessability, no extensions, no custom styles, ...

Yes it keeps coming up, yet Flash will have its revenge.

For a smallish subset of use cases, maybe. But replacing the DOM with a canvas-based UI for general use would be reinventing many of the problems of Flash.

Many designers and game devs see it otherwise.

Gamedev is a separate topic. As for designers, they are on the opposite side from users in the tug-of-war of control over content rendering. I don't believe they should get 100% of their way.

Gamedev falls squarely into my "smallish subset of use cases". It does legitimately need non-DOM UI, but it's not a huge part of the Web (yet).

As for designers, thank you for finding a much more diplomatic phrasing than the one I was about to write.

WebGL bindings are on the same footing as DOM bindings- they're not an alternative in this sense, because insofar as we have one we already have the other.

No because accessing WebGL contexts directly from WebAssembly, specially WebGPU ones, is something that keeps coming up in some Chrome presentations.

And thanks to many, including HN readership, Chrome and Safari are the only browsers that many businesses care about nowadays.

What I'm saying is, the feature/mechanism that lets WebAssembly call WebGL or WebGPU is exactly the same one that lets it call DOM APIs. The same implementation work supports both.

I looked into their WebAssembly demo, but it doesn't seem to use WebGL, just a regular DOM (with an ungodly number of elements).

That was just an example, maybe not the best one.

I should just have linked something done in Unity instead.

Uno uses DOM bindings, not WebGL.

Another benefit is initial page load times, if your page has a lot of JS it can take a pretty significant amount of time to parse it.

i.e. Figma said it reduced page load times by a factor of 3, though they were using WASM to replace existing asm.js code.

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

Another benefit I suppose is that you can choose from many more languages. Whether that is substantive or not depends on the person, I guess.

That's a use case, but there are many others, as the article mentions, like lightweight isolation for server side apps or writing your frontend app in a different language (not pragmatic today, but could be in the future).

Maybe that article can help about real world use case : https://tech.ebayinc.com/engineering/webassembly-at-ebay-a-r...

Thank you.