5 ms·

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

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.

kccqzy 5y ago
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.
- pjmlp 5y ago
  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.
- melony 5y ago
  > 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.
  - tyingq 5y ago
    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.
  - pjmlp 5y ago
    Like deploying MSIL DLLs and JVM Jars....
- hankman86 5y ago
  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.
  - staticassertion 5y ago
    > the very fact that threading isn't fully covered by the core wasm programming model Does any assembly language have a concept of threading?
    - tyingq 5y ago
      WASM is in many ways a virtual machine and not just an ASM dialect. Things like built-in garbage collection are in the plans.
- usrbinbash 5y ago
  > 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?
  - pjmlp 5y ago
    Business opportunities for new startups trying to sell it as a new idea.
  - des1nderlase 5y ago
    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)
    - usrbinbash 5y ago
      How exactly does WASM provide that better than, say, docker?
fulafel 5y ago
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).
- ignoramous 5y ago
  > 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.
  - fulafel 5y ago
    About the BG swap feature there's at least this blog post: https://ai.googleblog.com/2020/10/background-features-in-google-meet.html 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).

kccqzy 5y ago

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.

pjmlp 5y ago
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.
melony 5y ago
> 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.
- tyingq 5y ago
  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.
- pjmlp 5y ago
  Like deploying MSIL DLLs and JVM Jars....
hankman86 5y ago
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.
- staticassertion 5y ago
  > the very fact that threading isn't fully covered by the core wasm programming model Does any assembly language have a concept of threading?
  - tyingq 5y ago
    WASM is in many ways a virtual machine and not just an ASM dialect. Things like built-in garbage collection are in the plans.
usrbinbash 5y ago
> 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?
- pjmlp 5y ago
  Business opportunities for new startups trying to sell it as a new idea.
- des1nderlase 5y ago
  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)
  - usrbinbash 5y ago
    How exactly does WASM provide that better than, say, docker?

fulafel 5y ago

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).

ignoramous 5y ago
> 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.
- fulafel 5y ago
  About the BG swap feature there's at least this blog post: https://ai.googleblog.com/2020/10/background-features-in-google-meet.html 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).