I agree about WASM. I am sort of worried that Deno may be too late tbh. Why would I bother with an interpreted language at all when I can code in any language I want and run it anywhere with WASM?
The "any language" advantage of WASM is theoretical. Each language is at a different level of support of WASM, libraries aren't all caught up and at the same point for all languages, etc...
I love the promise of WASM, but every time I look at it I get lost in a sea of acronyms, and my optimistic ideas of using language X with library Y on runtime Z are dashed because there is some missing piece somewhere.
If anything, the "any language" thing creates a giant matrix of potential pitfalls for the programmer.
In comparison, the combination of JS/TS, the browser API and a solid std lib looks pretty good for some problems.
What is "any language" these days? I feel like WebAssembly's day will come when one of those is Javascript, and so far that hasn't happened.
Go's support is pretty good (with tinygo offering a tiny runtime more suited to this application). Rust appears to support compiling directly to WebAssembly, and there are some smaller languages like AssemblyScript and Lua with support. I'm guessing plain C works fine. Then there are projects that compile the runtime for interpreted languages to WebAssembly, so you can theoretically run things like Python.
Nobody is writing applications in C or AssemblyScript, so that leaves rust or go. If you're using one of those languages, though, you can just (cross-)compile a binary and copy it to a VM that is on some cloud provider's free tier, so this isn't really easing any deployment woes. It was already as easy with native code, so WebAssembly isn't adding much stuff here. (The isolation aspect was interesting in the days before Firecracker, but now every computer has hardware virtualization extensions and so you can safely run untrusted native code in a VM at native speeds.)
Anyway, I always wanted WebAssembly for two things: 1) To compile my React apps to a single binary. 2) To use as a plugin system for third-party apps (so I don't have to recompile Nginx to have OpenTracing support, for example). The language support hasn't really enabled either, so I'm a little disappointed. (Disappointed isn't really fair. I've invested no effort in this, and I can't be disappointed that someone didn't make a really complicated thing for me for free. But you know what I mean.)
> The isolation aspect was interesting in the days before Firecracker...
I don't think Firecracker's existence makes WASM's isolation uninteresting. First, I think you are looking at way more resources running a full VM (even a "micro" VM) compared to a WASM runtime. I think startup times are not comparable either, so if that matters you'll find WASM to be the way to go.
Second, WASM's capability-based security model is wonderful for giving the untrusted code the things it needs to work with. With a VM, you have to stitch together with shared directories, virtual eth bridges or, linux capabilities, maybe some cgroups, and who knows what else. (Granted you may need to do some of that with WASM too, but less so).
WASM still needs an interface layer to interact with the outside world (filesystem, etc.) My money is on WASI, but Deno becoming the interface layer has some advantages, mainly that most WASM-supporting languages already have tooling around JavaScript ffi.
I love the promise of WASM, but every time I look at it I get lost in a sea of acronyms, and my optimistic ideas of using language X with library Y on runtime Z are dashed because there is some missing piece somewhere.
If anything, the "any language" thing creates a giant matrix of potential pitfalls for the programmer.
In comparison, the combination of JS/TS, the browser API and a solid std lib looks pretty good for some problems.