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

> … it can't replace the encapsulation.

Can you explain your thoughts here? WebAssembly is sandboxed and effort must be expended to provide a mechanism for getting data through that boundary. How does that differ from “encapsulation?”



I'm referring to a different kind of encapsulation. Dependencies, tools, version management, configurations, environment variables, etc. Even if you can fully compile your code into WASM and host it on V8 you need to ship it with configuration files, set specific environment variables and so on. Containers allow you to bundle all of that together into a single unit you can share with others.


Note that it is possible to ship containers with configuration files and environment variables. Because Wasm imports can be virtualized (i.e.you could choose to fulfill a file-fetching interface completely or partially by composing two components together), it is possible to build a WebAssembly binary with what you need bundled.

Also, just because you could does not mean you should -- most of the time you don't want to inject environment variables or configurations that could contain secrets until runtime.


What about WASM doesn't encapsulate dependencies? Isn't it all one WASM blob at the end of the day?


That would be handled by the equivalent of a dockerfile/docker-compose.yml,


Unless you run the build in WASM itself. Are there any self-hosting WASM build chains?




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

Search: