4 ms·

Neither was Java at the time when browsers had support Java applets. At a closer look, Java Applets suffered from much of the same problems that plague WebAssem

Neither was Java at the time when browsers had support Java applets. At a closer look, Java Applets suffered from much of the same problems that plague WebAssembly. Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. Or the fact that you had to split up the code on your side into a JavaScript part (these days, perhaps transpiled from Typescript) and a part that was Java code then and is now Rust or C/C++ in case of WebAssembly. It goes without saying that these are very different developer experiences with virtually no overlap in toolchains and programming languages. Oh and of course even WebAssembly suffers from browser fragmentation. Not only will performance be different, depending on whether you run your wasm module in Chrome, Safari or Firefox. These browsers do also not implement the same feature set (atop the basic wasm MVP). Like Safari doesn’t have SIMD. Other important additions (like tail calls, garbage collection and others) are also not yet universally supported. For the sake of WebAssembly I do hope that they’ve learned their lessons from why Java applets (and Silverlight, Flash, PNaCl) all failed.

striking 5y ago
> Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. They're working on this. It's a tough problem, because someone has to own the resources. I don't think browser fragmentation is an issue for the same reason that CPU instruction set fragmentation isn't an issue: you can always compile to the lowest common denominator or ensure you are only running code segments that the target platform supports using runtime checks, just the same way we do it in native applications today.
trhway 5y ago
>Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. we did it more than 20 years ago :) A Java Applet could call directly (Java Applet -> Java DOM API and implementing it JNI of our plugin -> native XPCOM API of Mozilla including DOM API) native DOM API of the owning browser window as well as a Java application could embed Mozilla Gecko browser engine and call the native DOM API of that embedded browser: https://www-archive.mozilla.org/projects/blackwood/dom/ https://www-archive.mozilla.org/projects/blackwood/dom/
RantyDave 5y ago
Java also didn't have to face the fact that, now, Javascript runtimes are really good. There's not that much between Javascript and WASM ... and JS can access the DOM.
- pjmlp 5y ago
  Just like JavaApplets could.

striking 5y ago

> Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. They're working on this. It's a tough problem, because someone has to own the resources. I don't think browser fragmentation is an issue for the same reason that CPU instruction set fragmentation isn't an issue: you can always compile to the lowest common denominator or ensure you are only running code segments that the target platform supports using runtime checks, just the same way we do it in native applications today.

trhway 5y ago

>Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript. we did it more than 20 years ago :) A Java Applet could call directly (Java Applet -> Java DOM API and implementing it JNI of our plugin -> native XPCOM API of Mozilla including DOM API) native DOM API of the owning browser window as well as a Java application could embed Mozilla Gecko browser engine and call the native DOM API of that embedded browser: https://www-archive.mozilla.org/projects/blackwood/dom/ https://www-archive.mozilla.org/projects/blackwood/dom/

RantyDave 5y ago

Java also didn't have to face the fact that, now, Javascript runtimes are really good. There's not that much between Javascript and WASM ... and JS can access the DOM.

pjmlp 5y ago
Just like JavaApplets could.