3 ms·

I think the point people are making is that WebAssembly can't be a response to the prior shortcomings of the CLR/JVM because so many of the things being identif

I think the point people are making is that WebAssembly can't be a response to the prior shortcomings of the CLR/JVM because so many of the things being identified as shortcomings aren't (at least not in the latest versions), and so many basic features that you'd want aren't in WebAssembly. WASM exists mostly for political reasons as far as I can tell: it's something people who work on browsers can "own", vs outsource to other older teams with more historical baggage and different backing corporations. I mean, for WASM to be technically compelling you have to buy the idea that the best way to move the web forward is to enable applets-written-in-C without any useful form of DOM interop or GUI. That seems like a rather implausible claim.

haberman 8y ago
Are you suggesting that browsers should just embed a JVM or CLR? Those are huge runtimes that evolved independently of the design constraints of the web. Java Applets were available in browsers 20 years ago and lost to JavaScript. Why would JVM in the browser do any better now?
- repolfx 8y ago
  Lol. Java was absolutely designed for the web. Why do you think the main language of the web is called JavaScript? Java 1.0 came with the HotJava browser and Netscape 3 had a feature called LiveConnect that linked the JVM and the DOM together. As for embedding a JVM, sure, why not? Good JVMs are open source these days and HotSpot starts in 50 msec or less. V8 is very comparable, tech wise in terms of its approach. Lots of code out there targets JVM bytecode.
readittwice 8y ago
JVM-bytecode isn't ideal as a compilation target for C++, Rust, etc. And that's okay - it was designed for a different purpose. There are very good technical reasons for WASMs existence. JVM-Bytecode for example is very Java-focused, WASM doesn't need class-files or many bytecodes like invokevirtual. For supporting C++/Rust it doesn't even need GC. Bringing large applications like PSDFKit, AutoCAD or games into the browser is certainly getting the web forward. Sure, WASM isn't intended for manipulating the DOM. This is still JS's job (at least for the foreseeable future).

haberman 8y ago

Are you suggesting that browsers should just embed a JVM or CLR? Those are huge runtimes that evolved independently of the design constraints of the web. Java Applets were available in browsers 20 years ago and lost to JavaScript. Why would JVM in the browser do any better now?

repolfx 8y ago
Lol. Java was absolutely designed for the web. Why do you think the main language of the web is called JavaScript? Java 1.0 came with the HotJava browser and Netscape 3 had a feature called LiveConnect that linked the JVM and the DOM together. As for embedding a JVM, sure, why not? Good JVMs are open source these days and HotSpot starts in 50 msec or less. V8 is very comparable, tech wise in terms of its approach. Lots of code out there targets JVM bytecode.

readittwice 8y ago

JVM-bytecode isn't ideal as a compilation target for C++, Rust, etc. And that's okay - it was designed for a different purpose. There are very good technical reasons for WASMs existence. JVM-Bytecode for example is very Java-focused, WASM doesn't need class-files or many bytecodes like invokevirtual. For supporting C++/Rust it doesn't even need GC. Bringing large applications like PSDFKit, AutoCAD or games into the browser is certainly getting the web forward. Sure, WASM isn't intended for manipulating the DOM. This is still JS's job (at least for the foreseeable future).