Hacker News Reader

Comment by bargainbin | Hacker News Reader

To add to the discourse here, it's worth considering that since Elm came about WASM has come along in huge strides, and at this point you're faced with a "Why learn Elm when I can use <lang I already know> and compile to WASM".

See projects like Yew and Blazor.

View on HN

The issue I have with WASM is that its threading model is basically the web-worker model: each thread has to have its own module and can only communicate through pure data via shared memory.

TS/JS can do a lot these days, but threading is its achilles heel. Mechanisms like green threads and fast n-way dispatch for parallelization are basically still out of reach.

You can emulate some of this with WASM and worker pools, but it seems like you'd need a fair amount of boilerplate to actually make that work properly. And if you want to interface with native web APIs, you're stuck with the same limitations.

e.g. You can share memory with a web worker, but if you want to pass handles to resources around, you are extremely limited and it requires a custom approach for each particular API.

WASM is still not realistic for most apps especially if you care even a little about bundle size.

AssemblyScript produces the smallest binary and then Zig. Rust produces bloat binary by default but can be small by https://github.com/johnthagen/min-sized-rust for hello word type of app. I have no idea if the gc proposal could make those langs produce smaller binary size. That said, .wasm is generally smaller on wire and faster-to-execute on host.

Smallest binary compared to what? What will a typical AssemblyScript bundle size be like if it has similar functionality to a typical React app, let's say a todo app implementation?

Smallest compared to any of current capable compile-to-wasm langs. How dare you bring up React, when it's already lose to Solid which is apple-to-apple (js). React is freakin bloat. Numbers of functionality is the problems produced by itself and then solve its own problems.

If you ask me to compare to React for todo app, wasm with gc + interfacing with DOM, is going to blow React out of water in both size and performance (logic wise). DOM-wise, thing like "signal" already won anyway.

I honestly don't understand why you bring up React.

Any actual numbers from an actual comparison? Also, 'how dare you', lol, calm down dude.

Sorry about that I was saying in kidding tone. We're all good.

Here is the wasm binary size number (2019): https://stackoverflow.com/questions/55135927/how-do-webassem...

I didn't bookmark Zig and other for the number, it's over here and there on HN threads and Github issues.

---

I think you conflated "wasm binary size from AssemblyScript" with AssemblyScript size itself, that's why you brought up React to compare with AssemblyScript. AssemblyScript doesn't compete with React. And comparing React with the others is also tricky because of paradigm difference. React view and logic are very coupled. Compile-to-wasm langs only compete with js/ts part excluding the DOM part .. at least for now because wasm can't even share string ref right now (the "stringref" proposal is currently phase-1 ), let alone DOM access.

Wasm-gc proposal is already in phase-3. I think languages that used to also compile their runtime with app code could be smaller because wasm host manage collect the garbage for you in terms of "struct" and "array" (you can check out https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...)

> "Why learn Elm when I can use <lang I already know> and compile to WASM".

Especially now that Haskell is getting an official WASM backend.

Agreed. Also think Elm could benefit a lot from good interop with Wasm.

Reply on news.ycombinator.com