5 ms·

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

by 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?

by kccqzy 5y ago

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?