4 ms·
> Whereas all your service logic, database and endpoint code build into lightweight WASM modules that are dynamically loaded in-place by this global persistent
by jeremyjh 4y ago
> 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.
- azinman2 4y agoEverything old is new again!
- deleted 4y ago[deleted]
- tokinonagare 4y agoIt'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.
- anderspitman 4y ago> 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.
- jeremyjh 4y agoBusybox or other distribution tools are there for debugging purposes.
- tokinonagare 4y agoTrue. 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.
- Serow225 4y agoThe 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