Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



Just wait until they figure out WASM Application Servers, using serialised WebAssembly for server to server messages, now that would be an idea.


They could call it wRPC or something


Funnily enough, that's what [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/des...), largely based on [Core Wasm spec](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/) via WebTransport using wRPC: https://github.com/bytecodealliance/wrpc/tree/8e9de3b446ac05...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: