Staring at a gray box waiting for something to happen.

The solution to insanely deep open source tech stacks is to use simpler stacks. This is really my whole problem with the way JS is ubiquitously developed: you simply do not need 99% of the tools the JS devs are using these days. I use very simple full-stacks: so simple that I don't need a JS package manager (I do use pip/pypy, but I'm extremely guarded about what code I'll import--usually <10 packages). I do write some code that could be imported in a library sometimes, but I also barely ever do any rewriting to deal with deprecations, and my builds never break due to a package change. My builds are often reproduceable by accident.

In the short run, I'm not less productive than people who use all of npm. In the long run, I'm far more productive.

And even if that weren't the case, developer productivity at the expense of user security was a pretty bad tradeoff anyway. I really wish fewer people were doing that.

Wasm lets you take something that is coincidentally pure and run it in a way that ensures that it'll stay that way even for novel inputs, but you're still treating it like a black box... Just a particularly well behaved one.

Sometimes you need that because you're dealing with somebody else's code and they weren't especially interested in providing the kinds of assurances that you'd like to have. So I agree, it is a step in the right direction.

But if you want to author code that gives users such assurances, building to wasm is a rather small step. There only so much that can be done at the bytecode level. Much more can be done at a language level (Unison comes to mind, which goes so far as to eliminate the function's name as a source of works-differently-on-my-machine, though Haskell is probably a more common choice).