5 ms·
It's coming back via WebAssembly.
by jjordan 8y ago
It's coming back via WebAssembly.
- vbezhenar 8y agoWebAssembly can't do anything JavaScript can't do. Applets on the other hand have full access to computer and hardware. The only thing WebAssembly does better is performance and even that is questionable.
- lmz 8y agoNot any random applet, that's where the security manager comes in (in theory anyway).
- twic 8y agoApplets were heavily sandboxed. I think the only substantial things they could do that JavaScript can't were start threads and open TCP sockets (although still only to their origin host?). WebAssembly seems like a very good comparison.
- johannes1234321 8y agoYes they were sandboxed, but could request the user to approve further system access.
- vbezhenar 8y agoSigned applets could do anything, I wrote one myself to communicate with USB device.
- ktpsns 8y agoThe java applet's possibility to gently jump over the sandbox fence was probably the most terrifying feature of java which probably put Java on an equal footing as Adobe Flash, i.e. a potentially dangerous browser extension which requires regular updates (Flash and Java updaters were omnipresent in the Microsoft Windows tray in these days, isn't it?) and which the average user does not understand. That's a pity because both Adobe Flash as well as Java Applets were interesting pieces of software for certain applications. However, due to their availablity they were abused anywhere. I remember some 90s DHTML sites having one Java applet per navigation bar button just because the effect was looking nicely. This was the same kind of bloat we experience with huge JavaScript libraries today. Probably the browser plugins were even easier to control (i.e. disable as a user) as an ubiquitous JavaScript is :-/