Comment by sanderjd | Hacker News Reader

Comment by sanderjd | Hacker News Reader

Parent Full thread

I came here to ask something similar...

I feel like I really don't get wasm. It's not clear to me what problem we're trying to solve here...

Is the goal to be able to write applications in programming languages that aren't javascript or (transpiled to javascript)? Does that include writing the parts that interact with the browser's DOM presentation layer? I think my understanding is that you can't actually do that? If that's right, is the goal instead to be able to run applications in a dedicated canvas within the DOM, like how Flash worked? If so, how big is the niche for that?

Or somebody in a different thread mentioned using wasm for cloudflare workers. Because those work via a javascript interpreter, I guess? But, like, if people want to write cloudflare workers in arbitrary runtimes, couldn't cloudflare just add support for those other runtimes? Surely they have the wherewithal to do that...

Or is there something that is uniquely great about wasm as a bytecode, beyond its connection to the javascript ecosystem?

I just really feel like I've missed reading some introductory material on why this technology is exciting, but it's embarrassing to ask at this late point...

> Is the goal to be able to write applications in programming languages that aren't javascript or (transpiled to javascript)? Does that include writing the parts that interact with the browser's DOM presentation layer? I think my understanding is that you can't actually do that?

WasmGC, which is the proposal under current discussion, is one of the biggest steps towards that. You can't safely interact with the DOM if you can't pin references to the DOM. You can't pin references to the DOM if you can't let the JS VM garbage collect you (or otherwise understand your garbage collection needs).

(One of the demos mentioned in the article shows Dart/Flutter driving what seems to be a lot of DOM via GC pointers. I haven't dug in far enough to see exactly what the balance is between JS and Dart there, but it should be a lot closer than previous demos.)

Thanks, this is helpful.

The demo shows Flutter driving https://skia.org/docs/user/modules/canvaskit. It's just a single DOM node.

Ah, well then my disappointment in Dart/Flutter demos continues.

You can actually look at what wasm is currently being used for beyond its connection to the JS ecosystem. It's a really exciting space.

For example, there's a project called Oak (https://github.com/project-oak/oak) that basically allows your private information to be processed by servers without revealing them to the servers. It uses a bunch of technologies and wasm is a center piece for allowing a safe form of code execution.

For another example, check out Mozilla's post about securing Firefox with wasm (https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...). Again, here we compile C/C++ code with unknown memory safety properties into wasm and then compile that to native code. The benefit of doing it over directly compiling C/C++ to native code is that any memory safety issue is strictly sandboxed to be within the wasm module. You can't have one library's memory safety bug trampling over another library's memory.

There's one huge problem WASM solves compared to other existing solutions: memory safety. Instead of running untrusted computational code in a separate process, you can run it all in a single process since WASM linear memory has bounds checking. It also combines this with extremely constrained API access giving you a way to sandbox code with almost native performance.

Besides memory checking, there are much fewer nasty things a process can do in terms of control flow since executable memory (procedures) do not exist in linear memory. It supports function pointers via a separate table system (kind of like having a separate address space for executable memory). All of this is in place so if a WASM module crashes, it doesn't take down whatever process it's running in.

Current web browsers still act as a bit of a user agent, they allow the user to inspect what is happening and block certain elements from loading or displaying. The end goal is to re-implement the web browser within current browsers but with less user control and insight, and more tracking and ads.

Don't forget the goals of trashing accessibility, complicating security, and increasing the complexity of debugging.

To summarize the many good responses I've gotten (thanks!), which have helped my mental model a ton:

On the supportive side: Embedding arbitrary code (mostly, but not entirely in browsers) with secure sandboxing.

On the skeptical side: Just a way to make the browser less of a user agent and less accessible by running opaque code blobs.

Reply on news.ycombinator.com