Hacker News Reader

Comment by tester756 | Hacker News Reader

Great work, WASM is the future!

But on the other hand I'm not really happy with the fact that I'm waiting for GC and DOM access since 2019 or something like that

and it doesn't seem like we're getting close

View on HN

There has been a large amount of progress on wasm GC actually! If you haven't been attending the group meetings though then you might have missed it. In particular:

* The GC MVP spec is mostly done at this point.

* There are working toolchains for multiple languages: Java, Dart, Kotlin, and others have begun work as well.

* We will have a Phase 3 vote this week.

They just want to protect the frontend from the C#/Java crowd.

No chance, we're already compiling those to our wasm-based frontend apps

You can run Java in the browser now but at least you can't touch DOM...

What compromises does WASM have relative to plain old native code?

There are a few things we're excited about, many of which we fully recognize are used in marketing/buzzword bingo. But, they really are around portability (compile to a Wasm module and run on any architecture), isolated sandboxing (leveraging much of the research and investment used to protect web browsers), and super fast startups (obviously depends on the app too).

There are a few limitations right now, some of which lack of built-in garbage collection and multi-threading. You also have to use a language that can completely compile to Wasm, making it hard (sometimes impossible) to leverage already built libraries/binaries.

But... the tech is growing rapidly and we're excited for it! Happy to dive in or answer more questions if you'd like!

Yeah it's a super interesting topic, thanks for sharing!

A couple questions:

1. What use cases are you targeting, or which ones do you think have the most benefits from wasm?

2. What tools/stack are you currently using, or which ones do you think are the most promising?

One thing I've seen come up a lot is that people got used to treating containers as a portable unit of code, and then Apple Silicon threw a wrench in that assumption. A WASM module is the same regardless of whether you're running it on arm, amd, or anything. (Alas, the cost of this portability is that it's 32-bit)

Wasm = just a bunch of bytecode executing in a VM / a sandbox. Even with JIT, it will still be slower than the native code.

And since it is a sandbox.. either you, or your friendly wasm interpreter (via. wasi etc...) needs to provide the system access APIs for various things like storage/filesystem access, hardware acceleration via. GPU, TPU etc.. And some of the standard APIs we take for granted.

Is WASM typically interpreted? I would have assumed one of the advantages of an assembly language is it would be easy to JIT compile down to machine code.

That depends on the runtime. Some runtimes like wasmtime support both JIT and AOT compilation.

And for places where you can't use JIT compilation (like iOS... - which is where most of the users/developers of our app were) there are interpreters like wasm3.

Is wasm3 built in to iOS, or is that something you have to bundle with your app?

Wasm3 is just an interpreter you can/have to bundle with your app.

There was supposed to be a way to use the webassembly interpreter from JSCore but i am afraid my iOS knowledge doesn't go that far.

Reply on news.ycombinator.com