Hacker News Reader

Comment by jeremyjh | Hacker News Reader

> Whereas all your service logic, database and endpoint code build into lightweight WASM modules that are dynamically loaded in-place by this global persistent process

This sounds like J2EE application servers for WASM instead of Java byte code.

View on HN

It's exactly what it is, except there is also a browser implementation without plugin. Which also means that WASM/WASI is not a total replacement for containers: just like there as JVM image there will be WASI images. The argument of size given in the article isn't very convincing, when images like Alpine exist.

The problem addressed in the post is more about getting around Rust slow build time than phasing out containers. There's a lot of buzzwords (WASM, Rust, Cloud, etc.) but at the end of the day nothing that isn't easy to do with a modern "boring" stack like .NET.

The model they describe is pretty much exactly how .NET Azure Functions works. (which is however currently switching to a slightly different hosting model)

but that wouldn't bring in VC money lol

> The argument of size given in the article isn't very convincing, when images like Alpine exist

For a lot of uses you can go even smaller than Alpine. Static executables for example don't require standard Linux tools to operate. I expect WASI would be similar. Just drop the runtime and your Wasm files into a scratch container.

True. A static executable doesn't even need Linux in the first place, that can be done with a unikernel. It's a tradeoff about familiarity, size, performance, documentation and technical level.

Busybox or other distribution tools are there for debugging purposes.

Everything old is new again!

Reply on news.ycombinator.com