Unfortunately, Java is a bit of an archival nightmare. Java Applets can do pretty much anything they want, they aren't consistent in that sense. Unlike Flash you can't just run them offline in a Projector, and the code structure of an applet is different from that of a normal Java app. This is on top of being unable to play Java games without getting a tonne of (well deserved) security warnings (unless you want to pay Oracle $100 per month for a signature.) Java in the browser was just a bad idea all around.
Because it gives the Java programmer too much power in an environment that should be safe. For example there are applets like AppEmbed that can run an EXE in the browser. That's just insane. Flash and Shockwave in contrast are limited in that sense, you are constrained to doing what you are able to accomplish with ActionScript or Lingo (or at least, that is intended to be the case.) Flash is insecure because it's buggy, Java is insecure because it's buggy AND because it's intended to work in ways you'd think are obviously insecure!
Applets, unless especially privileged by the user, run in a sandbox that prevent them from interacting with the local OS [1]. They certainly cannot run EXEs, again, unless the user consents.
In theory the Applet sandbox works really well. It's an extremely secure environment that's been deployed widely in the most demanding conditions -- think banks and governments. In practice the Applet security model encountered the following problems:
(1) Users are really, really dumb. They are happy to grant escalated privileges to the some 3D farming game they stumbled upon on the internet. Users will literally click on anything you tell them to. [2]
(2) Getting users to upgrade Java was terribly difficult. This meant when a real security flaw was discovered it might hang around for years and years and years. There was no mechanism to force users to upgrade Java or to actively disable Java installations proven insecure.
Maybe I'm confused because it's only relatively recently that I started again to take Java seriously, but isn't that precisely an example of a domain the Java security manager addresses? Again, I am well aware of the implementation bugs that have existed, and I don't know offhand if the security manager was part of Java's initial design or was added later, but I'm still confused as to why your ire's directed at the general concept of Java in the browser, rather than the specifically flawed implementations.
There's just no safe way to do what Java applets enabled (arbitrary code execution), because of the massive attack surface. It's one reason why NPAPI is dead.
Java applets never enabled arbitrary code execution. (Where do people even come up with this stuff?) Spend five minutes on Google and you can learn about the Applet sandbox which prevented Applets from doing most anything but draw to a section of the browser window and connect back to their origin server (not unlike Javascript).
Yeah, what do you think the applet is run on? The JVM. That's the attack surface. And securing that went so well that everybody uses Java applets everywhere and applets are allowed by default (hint: securing it is impossible and they're disabled by default because of it).
Unfortunately Javascript-infested websites are a bit of an archival nightmare. Javascript can do pretty much anything it wants, it isn't consistent in that sense. You can't run them offline.
Javascript in the browser is just a bad idea all around.
You can generally "Save As..." and they tend to work just fine. Like any code which has network access, they can be dependent on various resources. I sometimes run a downloaded file through an insecure chrome instance (--disable-web-security and a unique --user-data-dir) with a catch-all service-worker. That'd probably not work with applets as they make their requests outside the browser AFAIK.
Also the security sandbox of Javascript is one of the best, if not the best. So it cannot do anything it wants.
Not everything is a chat application. But even a chat application can and should partially work without an internet connection: Reading old messages and composing new ones can work offline.
That has nothing to do with Javascript. If you use canonical, cacheable URIs for your requests, my method above works fine.
In my day job, I'm working on a CRM and sales system that is 100% web based and does work offline and is even offline-first (I love you Germany, but your mobile network sucks).
There may be many other problems with it but offline is mostly a solved problem in the web world.
Quick experiment: In a new Firefox profile, I opened a couple of websites [1]. Then I went offline and tried to load them again. Every time I just got the default "server not found" page of Firefox.
"Offline" is no more solved "not hijacking scrolling", "linkable URLs" and "not re-inventing <a href> badly".
Did you try right clicking and choosing "Save as..."?
As I said before, it's a 5-minute thing to get started with service-workers. Web-sites can use that and then you don't even need to save. There is this great offline library, fellow developers! Use it! What other platform gives you such easy-to-use offline capabilities?
> As I said before, it's a 5-minute thing to get started with service-workers. Web-sites can use that and then you don't even need to save.
I don't care if websites can use that if they don't.
> You are dealing with a Turing-complete language here.
That's the fucking problem.
> What is the alternative you are supporting instead the current situation?
Using a proper application platform instead of a pile of hacks on top of the web. Without that pile of hacks, the web would actually be usable because publishers would not be able to break the UX.
