Hacker News Reader

Comment by hinkley | Hacker News Reader

I was even trying to be charitable and read the feature list for elements that would thin down a third party DOM access layer, but other than the string changes I’m just not seeing it. That’s not enough forward progress.

WASM is just an extremely expensive toy for browsers until it supports DOM access.

View on HN

It's a chicken egg situation. The people already using WASM either don't care about the DOM or had realized long ago that going through a JS shim works just as well, the rest just complain time and time again that WASM has no DOM access whenever there's a HN thread about WASM, but usually don't even use WASM for anything.

Especially if there was major momentum of people writing their web applications with wasm, there would be a reason to eventually get that massive undertaking of creating the ABI for that working. Then all those applications could just recompile to make use of this new hypothetically faster API. The bigger issue here is that it just doesn't make any sense to write frontend code in rust or go or whatever in the first place.

The whole js ecosystem evolved to become a damn good environment to write UIs with, people don't know the massive complexity this environment evolved to solve over decades.

I feel like this is asking for a jquery for WASM. All you need are css selectors and verbs. The selector is a choke point that keeps you from having to create a concrete object on both sides of the FFI. And the fact that jquery is built for bulk operations would also be a feature you’d want to preserve for performance reasons.

My old team shipped a web port of our 3D modeling software back in 2017. The entire engine is the same as the desktop app, written in C++, and compiled to wasm.

Wasm is not now and will never be a magic "press here to replace JS with a new language" button. But it works really well for bringing systems software into a web environment.

The three main camps of wasm use cases are ( in no particular order )

1. Non browser application (lightweight cloud, plugins, sandboxing)

2. Performance kernels (like compiling a game/rendering engine or AI stuff)

3. Compiling js-like applications from other languages (eg blazor wasm and others)

The only case where DOM access would be useful is 3 and even there 90% of the gains are already available from the JS-strings proposal to avoid copying+reencoding.

Direct DOM access is otherwise mostly a red herring

Reply on news.ycombinator.com