|
|
|
|
|
by jeroenhd
475 days ago
|
|
Web applets were a terrible experience all round. Downloaded JAR files usually just worked, though. The GUI looked odd because it wasn't using normal operating system controls, but in terms of performance it was no slower than any native program except for in the most extreme cases. Java on the web was pretty terrible from beginning to end, but The Java Web could've worked. Now that we have the web, we're moving back to the Javaverse in the form of apps (which, on Android, are actually Java(-like)). Every big website has one of those "for the full experience, download our app" banners. Other sites use WASM to bring back the Java applet days, now without third party plugin full of security holes. Google Docs renders to a virtual canvas in the browser in the same way an applet would've back in 2003, except it would've been able to open files directly from the file system. And lo and behold, the new system is also a terrible experience. |
|
I'd have said the situation back then was a bit better than that - a Java applet wouldn't have been able to access your filesystem by default, for instance.
Part of the benefit of Sun's Java was that the bytecode itself could be statically verified to only have good behaviour and the plugin would then sandbox what it could access at runtime. The plugin itself would obviously have had bugs - like all software - but it's not obvious to me that was intrinsically worse than having all that code as part of the browser (as we do now).
I'd contrast it with ActiveX and (I think), which was very free about what its applets could do (basically just Windows executable code, I think). Flash I'm less clear on the limitations of.
We have moved on in other ways, of course - browsers are architected to isolate processes more, including use of things like seccomp.