61–70 of 371 posts
What sort of tooling is required for wasm? Let's say I wanted to deploy a middle tier in our app, consisting of some nodejs code that talks to an external database. We'd use a Dockerfile, install nodejs or use a source image to build from. How does that work for wasm? Does it have layers to reuse?
No. Wasm is not useful enough yet. Neither are containers.
This is demonstrably false.
I don't doubt that wasm has potential, but personally I imagine more esoteric use cases as the go to than necessarily the replacement for containers (where my money is more on unikernel).
Also, I think most uses of containers lose the advantage of WASM. WASM is about running on any platform, great for browsers and serverless. But containers are usually run in controlled environment where can compile once and not pay the penalty of compiling each time.
You underestimate developers. WASM will never replace containers. People will be running wasm inside of containers. That's what will happen.
WASM to an API is essentially the `Fn(…) -> …` type. E.g., you have
POST /some/api
And across the board, what APIs/aaS's do is that some PM goes "I think these are the only 2 things anyone will ever want", those get implemented, and you get an enum in the API, the UI, the service, etc. And that's all it is ever capable of, until someone at the company envisions something bigger.
If I could pass WASM, I could just substitute my own logic.
Like webhooks, but I don't have to spin up a whole friggin' HTTP server.
> WebAssembly is a true write-once-run-anywhere experience.
Except not. The wasm ISA is really quite limited in the types of operations. A full-blown RISC/CISC ISA will have way more opportunities for optimization. To say nothing of multithreading and pipelining. JITing also has overhead.
> You can compile several languages into WebAssembly already.
But if you can compile them, why not just compile to container, and get free performance?
Wasm will have a hard time with anything low level: networking, I/O, GPU, multimedia codecs.
"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…