> 1. Large runtimes and std libs. Indeed. With the web's model, it seems tempting to make the browser cache do the work for you by putting the language runtime

> 1. Large runtimes and std libs. Indeed. With the web's model, it seems tempting to make the browser cache do the work for you by putting the language runtime at a standard URL. That works, modulo the security features today that cache Wasm modules per-origin to avoid an engine JIT bug creating a cross-origin vulnerability. GC helps a bit with that in the sense that the GC algorithm itself moves down into the engine. > 2. You need a JIT for performance. I worked a bit on a prototype JVM on Wasm that used the Wasm bytecode format to encode Java constructs. That helps because then you don't have another bytecode interpreter running on level up, but ultimately you want somewhat more control over the JIT and the code it generates. Wasm engines supporting dynamic code generation at all (any finer-grained than a module) would help a lot there. Compiling V8 whole-hog seems like it would take a lot of doing. In particular, it has JITs and an interpreter that want to spit out machine code. That'd have to be replaced with Wasm backends. > It seems we ended up with WASM more due to Mozilla politics than what makes sense technically. The politics were...complicated. I'd tell my side but it's probably best I don't.