3 ms·

> Which will always be the best DX for writing code in the browser. The article we're all commenting on is not about running WASM in the browser. WASI in part

> Which will always be the best DX for writing code in the browser. The article we're all commenting on is not about running WASM in the browser. WASI in particular may never be supported by browsers.

zero_shift 2y ago
I'm aware of the article's context but am asking the broader question.
- boomskats 2y ago
  > I'm aware of the article's context but that just raises further questions. Why invest much effort, as a developer, or as a vendor, in a version of WASM that doesn't even let you run client side? It's carving an ever smaller niche. Because of the value it can deliver server-side, and that's where most of the value tends to be. Server-side compute is the core of most companies' revenue streams, yet it really is bloating out of control. Think about how much money is wasted on build pipelines, artifact storage, giant image distribution, multi-tenant workload isolation, supply chain risk mitigation; how expensive cloud infrastructure is, and what a substantial share of it is spent on all of those. With the way WASM was designed, it has the potential to completely upend all of it: tiny binaries, sandboxed runtimes, tightly knit mt, instant scaling, clearly defined contracts, language agnostic microservices. It's a completely different world. The potential for WASM in enterprise compute is immense - especially with the recent developments in the component model and WASI. We're talking about orders of magnitude improvements here.
  - pjmlp 2y ago
    Just wait until they figure out WASM Application Servers, using serialised WebAssembly for server to server messages, now that would be an idea.
    - boomskats 2y ago
      They could call it wRPC or something
      - rvolosatovs 2y ago
        Funnily enough, that's what [wRPC](https://github.com/bytecodealliance/wrpc https://github.com/bytecodealliance/wrpc) is designed to do, using the small and efficient [Component Model Value Encoding](https://github.com/WebAssembly/component-model/blob/main/design/mvp/Binary.md#-value-definitions https://github.com/WebAssembly/component-model/blob/main/des...), largely based on [Core Wasm spec](https://webassembly.github.io/spec/core/ https://webassembly.github.io/spec/core/). For example, here's an example of a Web App using [`wasi:keyvalue` interface](https://github.com/WebAssembly/wasi-keyvalue/ https://github.com/WebAssembly/wasi-keyvalue/) via WebTransport using wRPC: https://github.com/bytecodealliance/wrpc/tree/8e9de3b446ac05810d8a5fa2b90a5f4e5b7fe871/examples/web https://github.com/bytecodealliance/wrpc/tree/8e9de3b446ac05...
pjmlp 2y ago
And on that regard, there are more mature options out there, than reinventing the wheel with WebAssembly.
- coder543 2y ago
  Do those "more mature" options support architecture-independent executables written in Rust or Go, so that a company doesn't need to rewrite their existing code in Java?
  - pjmlp 2y ago
    Well, depends if they target LLVM IR, or .NET MSIL. https://www.graalvm.org/latest/reference-manual/llvm/ https://www.graalvm.org/latest/reference-manual/llvm/ https://github.com/FractalFir/rustc_codegen_clr https://github.com/FractalFir/rustc_codegen_clr Also ever heard about containers? They have this magic feature, you don't need to rewrite anything to run on servers.
    - coder543 2y ago
      Containers are a much heavier way to implement a plug-in system, since you will also need to define an RPC of some kind, and they're not architecture-independent unless you require the users to build every container for every architecture. Containers generally aren't a security boundary, but you can wrap them in something like firecracker to help with that. (I believe plugins were an essential part of the context, based on the post we're commenting on, so it is important to evaluate these options against that.) LLVM IR as it is actually generated is also not architecture independent, and not a security boundary, making it a poor way to do a plugin system. Definitely not more mature for this type of stuff. .NET MSIL is probably a better fit than the other two options you provided, but not a good one... I don't think Go or Rust compile to MSIL, and MSIL probably isn't a very good security boundary anyways. I know from past discussions that you don't like WASM. I think you're overly dismissive of it. WASM has been around long enough now that it is a fairly mature system. I haven't personally needed it, but that's simply a comment on my own work experience, not the usefulness of the technology for specific use cases... and I can easily see why people are passionate about WASM. It's not NIH syndrome.

zero_shift 2y ago

I'm aware of the article's context but am asking the broader question.

boomskats 2y ago
> I'm aware of the article's context but that just raises further questions. Why invest much effort, as a developer, or as a vendor, in a version of WASM that doesn't even let you run client side? It's carving an ever smaller niche. Because of the value it can deliver server-side, and that's where most of the value tends to be. Server-side compute is the core of most companies' revenue streams, yet it really is bloating out of control. Think about how much money is wasted on build pipelines, artifact storage, giant image distribution, multi-tenant workload isolation, supply chain risk mitigation; how expensive cloud infrastructure is, and what a substantial share of it is spent on all of those. With the way WASM was designed, it has the potential to completely upend all of it: tiny binaries, sandboxed runtimes, tightly knit mt, instant scaling, clearly defined contracts, language agnostic microservices. It's a completely different world. The potential for WASM in enterprise compute is immense - especially with the recent developments in the component model and WASI. We're talking about orders of magnitude improvements here.
- pjmlp 2y ago
  Just wait until they figure out WASM Application Servers, using serialised WebAssembly for server to server messages, now that would be an idea.
  - boomskats 2y ago
    They could call it wRPC or something
    - rvolosatovs 2y ago
      Funnily enough, that's what [wRPC](https://github.com/bytecodealliance/wrpc https://github.com/bytecodealliance/wrpc) is designed to do, using the small and efficient [Component Model Value Encoding](https://github.com/WebAssembly/component-model/blob/main/design/mvp/Binary.md#-value-definitions https://github.com/WebAssembly/component-model/blob/main/des...), largely based on [Core Wasm spec](https://webassembly.github.io/spec/core/ https://webassembly.github.io/spec/core/). For example, here's an example of a Web App using [`wasi:keyvalue` interface](https://github.com/WebAssembly/wasi-keyvalue/ https://github.com/WebAssembly/wasi-keyvalue/) via WebTransport using wRPC: https://github.com/bytecodealliance/wrpc/tree/8e9de3b446ac05810d8a5fa2b90a5f4e5b7fe871/examples/web https://github.com/bytecodealliance/wrpc/tree/8e9de3b446ac05...

pjmlp 2y ago

And on that regard, there are more mature options out there, than reinventing the wheel with WebAssembly.

coder543 2y ago
Do those "more mature" options support architecture-independent executables written in Rust or Go, so that a company doesn't need to rewrite their existing code in Java?
- pjmlp 2y ago
  Well, depends if they target LLVM IR, or .NET MSIL. https://www.graalvm.org/latest/reference-manual/llvm/ https://www.graalvm.org/latest/reference-manual/llvm/ https://github.com/FractalFir/rustc_codegen_clr https://github.com/FractalFir/rustc_codegen_clr Also ever heard about containers? They have this magic feature, you don't need to rewrite anything to run on servers.
  - coder543 2y ago
    Containers are a much heavier way to implement a plug-in system, since you will also need to define an RPC of some kind, and they're not architecture-independent unless you require the users to build every container for every architecture. Containers generally aren't a security boundary, but you can wrap them in something like firecracker to help with that. (I believe plugins were an essential part of the context, based on the post we're commenting on, so it is important to evaluate these options against that.) LLVM IR as it is actually generated is also not architecture independent, and not a security boundary, making it a poor way to do a plugin system. Definitely not more mature for this type of stuff. .NET MSIL is probably a better fit than the other two options you provided, but not a good one... I don't think Go or Rust compile to MSIL, and MSIL probably isn't a very good security boundary anyways. I know from past discussions that you don't like WASM. I think you're overly dismissive of it. WASM has been around long enough now that it is a fairly mature system. I haven't personally needed it, but that's simply a comment on my own work experience, not the usefulness of the technology for specific use cases... and I can easily see why people are passionate about WASM. It's not NIH syndrome.