4 ms·

If you could Applet.instantiate() as easily as WebAssembly.instantiate() and have Java methods immediately available from JavaScript, I have no doubt that it wo

by panic 5y ago

If you could Applet.instantiate() as easily as WebAssembly.instantiate() and have Java methods immediately available from JavaScript, I have no doubt that it would be as successful as WASM is. The advantage of WASM is that it’s already integrated with JavaScript VMs in a way that Java never was. Though I suppose it’s possible if someone wants to get V8 running JVM bytecode!

PaulDavisThe1st 5y ago
So your argument there is "well, I can access WASM from javascript more easily that I could access Java" ? That's it?
- panic 5y ago
  Yes—in most cases the technology itself doesn’t matter as much as how it can be deployed. The popularity of JavaScript itself is testament to that (though the technology has caught up quite a bit there).
pjmlp 5y ago
Except it actually was, as there was an interop API for applets to interact with DOM and vice-versa.
- panic 5y ago
  You're right, and not just the DOM: https://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html https://docs.oracle.com/javase/tutorial/deployment/applet/in... Maybe the real reason has to do with security, then? That was the justification for removing Java support from browsers, leaving the door open for WASM to take its place.
  - pjmlp 5y ago
    Politics, https://en.m.wikipedia.org/wiki/Google_Native_Client https://en.m.wikipedia.org/wiki/Google_Native_Client https://adobe-flash.github.io/crossbridge/ https://adobe-flash.github.io/crossbridge/ https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat...
    - josephg 5y ago
      There's also technical reasons galore: - NaCL (as I understand it) essentially enshrined a particular version of llvm bytecode as its data format. This made it overcomplicated, and made it very difficult (technically and politically) for other browsers to implement any of it. It was difficult to compile to, and only supported chrome (which was at the time much less dominant than it is now). But webassembly is like NaCL 3.0 anyway. (2.0 was asmjs). Webassembly is NaCL's successor, not its rival. - Flash was always a firehose of security vulnerabilities, and using it tied the future of the web to an (essentially) proprietary format put out by a single company. Flash never worked well on mobile - when it worked at all it turned your phone into a pocket heater. It didn't help that so many banner ads were distributed via flash. And given how badly flash integrated with the browser's scheduler that meant a background tab turned your computer into a space heater. Ultimately flash was killed by adobe's failure to ship a good enough product. - Java in the browser had nearly as many security issues as flash did. And it took seconds for the jvm to start up. When it worked at all that is - java applets relied on the user to have a reasonably up-to-date version of the JVM installed (and appropriate browser extensions). Even as a developer it was a pain to get java applets working. And for what benefit? So we could have ugly non-native controls? It could have worked if browser vendors all shipped a properly sandboxed lightweight JVM like they started to do with flash. But nobody used applets anyway because they barely worked on anyone's computers. Webassembly has taken all of the lessons from this to heart and taken 2 really important steps that no competing system has achieved: 1. Webassembly only runs in a completely sandboxed, bounds checked memory container with a tiny surface area. As a result it is orders of magnitude more secure than flash or java. 2. Webassembly got buy-in from browser vendors. Because the browsers are in charge of their respective wasm virtual machines, they're extremely well integrated with the rest of the browser. Wasm has solid JS APIs, it works everywhere including mobile, it starts up instantly (unlike java), and its tied to browsers' update mechanisms. Yeah, politics were involved. But the outcome is much better than we would have achieved with flash or java. And I'm very grateful for the outcome. I don't want to need proprietary junk from Adobe and Oracle to make the web work.
      - PaulDavisThe1st 5y ago
        > 1. Webassembly only runs in a completely sandboxed, bounds checked memory container with a tiny surface area. Which is mostly sort of great in a browser context. But WASI appears to be pushing WASM for use outside the browser context, and for this to really make sense, the restruction in your #1 would need to be severely relaxed and/or substantial and large modules added to facilitate interaction with the underlying host system. Of course some of this happened at the browser level already: web audio, web usb as the two main examples. But as that keeps happening, the "tiny surface area" feature also gets a little harder to claim.

by panic 5y ago

PaulDavisThe1st 5y ago

So your argument there is "well, I can access WASM from javascript more easily that I could access Java" ? That's it?

panic 5y ago
Yes—in most cases the technology itself doesn’t matter as much as how it can be deployed. The popularity of JavaScript itself is testament to that (though the technology has caught up quite a bit there).

pjmlp 5y ago

Except it actually was, as there was an interop API for applets to interact with DOM and vice-versa.

panic 5y ago
You're right, and not just the DOM: https://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html https://docs.oracle.com/javase/tutorial/deployment/applet/in... Maybe the real reason has to do with security, then? That was the justification for removing Java support from browsers, leaving the door open for WASM to take its place.
- pjmlp 5y ago
  Politics, https://en.m.wikipedia.org/wiki/Google_Native_Client https://en.m.wikipedia.org/wiki/Google_Native_Client https://adobe-flash.github.io/crossbridge/ https://adobe-flash.github.io/crossbridge/ https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat...
  - josephg 5y ago
    There's also technical reasons galore: - NaCL (as I understand it) essentially enshrined a particular version of llvm bytecode as its data format. This made it overcomplicated, and made it very difficult (technically and politically) for other browsers to implement any of it. It was difficult to compile to, and only supported chrome (which was at the time much less dominant than it is now). But webassembly is like NaCL 3.0 anyway. (2.0 was asmjs). Webassembly is NaCL's successor, not its rival. - Flash was always a firehose of security vulnerabilities, and using it tied the future of the web to an (essentially) proprietary format put out by a single company. Flash never worked well on mobile - when it worked at all it turned your phone into a pocket heater. It didn't help that so many banner ads were distributed via flash. And given how badly flash integrated with the browser's scheduler that meant a background tab turned your computer into a space heater. Ultimately flash was killed by adobe's failure to ship a good enough product. - Java in the browser had nearly as many security issues as flash did. And it took seconds for the jvm to start up. When it worked at all that is - java applets relied on the user to have a reasonably up-to-date version of the JVM installed (and appropriate browser extensions). Even as a developer it was a pain to get java applets working. And for what benefit? So we could have ugly non-native controls? It could have worked if browser vendors all shipped a properly sandboxed lightweight JVM like they started to do with flash. But nobody used applets anyway because they barely worked on anyone's computers. Webassembly has taken all of the lessons from this to heart and taken 2 really important steps that no competing system has achieved: 1. Webassembly only runs in a completely sandboxed, bounds checked memory container with a tiny surface area. As a result it is orders of magnitude more secure than flash or java. 2. Webassembly got buy-in from browser vendors. Because the browsers are in charge of their respective wasm virtual machines, they're extremely well integrated with the rest of the browser. Wasm has solid JS APIs, it works everywhere including mobile, it starts up instantly (unlike java), and its tied to browsers' update mechanisms. Yeah, politics were involved. But the outcome is much better than we would have achieved with flash or java. And I'm very grateful for the outcome. I don't want to need proprietary junk from Adobe and Oracle to make the web work.
    - PaulDavisThe1st 5y ago
      > 1. Webassembly only runs in a completely sandboxed, bounds checked memory container with a tiny surface area. Which is mostly sort of great in a browser context. But WASI appears to be pushing WASM for use outside the browser context, and for this to really make sense, the restruction in your #1 would need to be severely relaxed and/or substantial and large modules added to facilitate interaction with the underlying host system. Of course some of this happened at the browser level already: web audio, web usb as the two main examples. But as that keeps happening, the "tiny surface area" feature also gets a little harder to claim.