Hacker News Reader

Comment by hankman86 | Hacker News Reader

There are many things to love about WebAssembly, but let’s not forget it’s downsides. Like it’s threading model relies on Web workers and SharedArrayBuffers and is a royal pain in the … to work with. Not to mention that you’ll need to become COOP/COEP compliant to mitigate side-channel attacks.

Then there is the plain fact that it requires a compilation step, which is OK for large apps. But it makes me wonder if wasm really is the natural replacement for JavaScript in serverless cloud apps (aka “FaaS”).

So yes, WebAssembly has potential and is almost without an alternative for in-browser apps that do some heavy compute. But I am less convinced about server-side. Time and again, we’re told how great portability across architectures supposedly is. And time and again, the only cloud architecture that matters is x86-64. Maybe ARM or even RISC-V in some cases, but let’s not fool ourselves about these niche platforms.

View on HN

WebAssembly itself is independent of the web or the browser. Therefore it is impossible for it to depend on Web Workers or SharedArrayBuffers. Rather it is the browser implementation of WASM (the embedder) that uses these technologies you seem to hate.

Just think about it, you even mentioned serverless cloud apps. Are these cloud apps going to run inside a browser and therefore use Web Workers for threading? The answer is obviously no.

WASM itself merely provides shared memory and instructions needed in multithreaded environments like i32.atomic.rmw.cmpxchg and i32.atomic.store, but it doesn't stipulate how threads are created.

I don't blame you but lots of people confuse WASM itself with the browsers' implementation of WASM (which, among other things, decides which functions are imported into WASM and how they work). But to me, the most exciting future of WASM is outside the browser. So we must clearly delineate features of WASM from the browser-specific bits.

> Just think about it, you even mentioned serverless cloud apps. Are these cloud apps going to run inside a browser and therefore use Web Workers for threading? The answer is obviously no.

Yes actually. CloudFlare and several other cloud providers are trying to push towards V8 based sandboxing on the edge instead of the node-in-KVM model used by firecracker because the former is lighter and easier to deploy.

That's more of a "sort of". It is V8, but no "webworkers as threads", and then things like the cache api, cron-like scheduling, k/v store and durable objects added on.

Like deploying MSIL DLLs and JVM Jars....

Oh, I have implemented wasm multi-threading both in-browser and on a node server. On the latter, it uses node's "Worker threads" API, which is very similar to in-browser Web workers. In either case, `SharedArrayBuffer` serves as the backing store for the (shared) `WebAssembly.Memory`. Wasmer is different and more like what WebAssembly should offer as part of the standard. Alas, that's not how wasm works in-browser.

But anyway, I think you confuse my point: the very fact that threading isn't fully covered by the core wasm programming model, but relies on a "hybrid" approach where the embedder needs to plug in those capabilities is a problem. Before wasm, I used Google's PNaCl quite heavily, which didn't suffer this problem and was fully self-contained.

> the very fact that threading isn't fully covered by the core wasm programming model

Does any assembly language have a concept of threading?

WASM is in many ways a virtual machine and not just an ASM dialect. Things like built-in garbage collection are in the plans.

Looking at history from polyglot bytecodes in computing since 1960, there is hardly anything exciting about WASM on the server besides business opportunities to jump into WASM gold rush.

> WebAssembly itself is independent of the web or the browser.

Sure it is, but let me, a backend developer, ask a question:

Why would I want to use WASM for anything running on my server, when I can just write it in Golang, and get actually native performance (not "near-native"), plus real GC, on top of an already thriving ecosystem of libraries and tools?

And lets replace Golang with Rust, C, C++, or Java, or even with a more dynamic language like Python or node if its not performance-critical...the question remains.

My point is, why would I use WASM for something other than what it was originally designed for (running things in the browser), when I already have a big collection of really powerful, established, stable, well supported backend Languages?

What does WASM bring to the backend-table that the current tools cannot provide, or provide badly?

Business opportunities for new startups trying to sell it as a new idea.

If you are building multi-tenant backend for i.e. SaaS app and you want to provide better isolation between your tenants (than relying on hardening, security/pen testing of your own code, or want to allow user/3rd party code to execute on your BE)

How exactly does WASM provide that better than, say, docker?

The only significant perf advantage WebAssembly has in browser vs JS is currently access to (Pentium II era) SIMD. This is a regrettable choice, because most languages targeting the browsers are now lacking access to SIMD.

Heavier computation is currently being done with WebGL shaders (eg Google Meet background swap, TensorFlow tfjs).

> Heavier computation is currently being done with WebGL shaders

Re: in-browser heavy-computation: Where can I learn more about these patterns to get started? Books / blogs? Thx.

About the BG swap feature there's at least this blog post: https://ai.googleblog.com/2020/10/background-features-in-goo...

Rereading the blog post, they do seem to use WebAssembly as well there and the abovementioned SIMD feature (through XNNPACK).

Reply on news.ycombinator.com