This "long-held fervor" that culminated in WASM started back before Node.js existed, so back then, "Javascript" was just a thing browsers did (except for, say, Windows Scripting Host's support of it.) The fervor back then wasn't really driven by a desire for a ubiquitous anything; it was driven specifically by people thinking about browsers, and what is required to program web-apps in browsers.

What people have wished for, since... oh, 2001 or so, is the ability to write web-app frontends without needing to grok and deal with the awful runtime semantics of Javascript—the way you do when you write Javascript, yes, but also the way you do when you write in a language that directly transpiles to Javascript, like TypeScript or ClojureScript.

Languages like TypeScript may add semantics on top of the JS runtime's semantics, but they can't get away from the fact that the JS runtime is the "abstract machine" they program, any more than e.g. Clojure can get away from the fact that the JVM is the abstract machine it programs. That's why none of these languages were ever seen as a "saving grace" from the "problem of Javascript", the way WASM is.

WASM has its own abstract machine (which runs efficiently in browsers), which finally frees people from the tyranny of the Javascript-runtime-as-abstract-machine.

It's great that it's also now replacing the Javascript-runtime-abstract-machine in other contexts (e.g. Node-like server-side usage, plain-V8-like embedded usage) but that was never really "the thing" that anyone cared about.

---

Mind you, the NaCl fervor was for a ubiquitous VM—but the NaCl fervor wasn't nearly as large, and isn't really what's propelling WASM to prominence right now. Even then, it wasn't about "an easy garbage collected language that is ubiquitous", no. The goal of it was to be able to take code that you already have—native code, written to run fast, like a AAA game—and put it in a browser-strength sandbox, such that it can be zero-installed just by visiting a URL, with full performance. You know, like ActiveX was supposed to be. But better.

NaCl didn't really get us there, because it happened right as the architectural split between x86 and ARM really started heating up, and NaCl's solution to that split—PNaCl, a.k.a. sandboxed LLVM IR—was both too late and not really efficient-enough at the time to fully supplant the "Native" NaCl in NaCl messaging. (LLVM IR works well-enough now for Apple to rely on it for being a "unified intermediate" of both x86 and ARM target object code, but that shift only began with ~8 additional years of LLVM development after the version of LLVM that PNaCl's IR came from.)

WASM seems to get us there. But do we care any more? Everyone already has other solutions to this problem. ChromeOS can run Android apps; Ubuntu Snappy packages can expose GUIs to Wayland; Windows has a Linux ABI to run Docker containers. Ubiquity is a lot easier now than it was back then, for any particular use-case you might want.

On the embedded-scripting side of things, everyone has seemingly settled on embedding LuaJIT or V8. Do people even need embedded scripts to be fast, in a way that "WASM as compilation target" would help with? Maybe for the more esoteric use-cases like CouchDB's "design documents" or the Ethereum VM (https://medium.com/coinmonks/ewasm-web-assembly-for-ethereum...) But I doubt WASM will hit ubiquity here. Why would OpenResty switch? Why would Redis? Etc. You're not writing-and-compiling native code for any of these in the first place, so adding WASM here would only break existing workflows.