> In the 2000's, politics interfered and browser vendors removed plug-in support, instead preferring their own walled gardens and restricted sandboxes
That's one way to say it. The more common way was that users got tired of crappy plugins crashing their browsers, and browser devs got tired of endless complaints from their users.
It wasn't "politics" of any sort that made browsers sandbox everything. It was the insane number of crashes, out-of-memories, pegged CPUs, and security vulnerabilities that pushed things over the edge. You can only sit through so many dozens of Adobe 0-days before it starts to grate.
A coworker of mine that worked at Adobe through the death of flash said a big reason for that death was Apple deciding the Ipod touch Safari would not support plugins.
Adobe had big plans on the Ipod supporting Flash and that announcement all but killed their Flash division.
Yes, Adobe supported Flash for years after that, but it was more of a life support thing and not active development. They saw the writing on the wall and knew that for flash to survive, it had to survive in a mobile world.
With the decreased support of flash, the other browser devs simply followed suit and killed off a route for something like Flash running in a browser.
The only thing worse than launching the JVM from the command line, with it's looooooooooooong and inexplicable load time, was hitting a web page and having it lock the browser for that amount of load time.
I remember a few decades ago somebody saying the JVM was incredible technology, and as a user and programmer I still have zero clue what the hell they could have been thinking was good about the JVM.
I hear that now, decades into Java, they have figured out how to launch a program without slowing a computer down for 10+ seconds, but I'll be damned if I find out. There are still so many rough edges that they never even bothered to try to fix about launching a .jar with classpath dependencies. What a mess!
>I still have zero clue what the hell they could have been thinking was good about the JVM.
Running one packaged program across every platform. Write once, run anywhere was Sun's slogan for Java. (Though oftentimes ended up being debug anywhere.) As for the slow start part, programs can either be often-launched short-running or seldom-launched forever-running. Assume because enterprise software falls to the later part (and runtime performance > startup time + memory use), focus was there.
Not sure if I get this: WASM lets you use any language in the browser, though it still works way better with languages without GC, such as Rust or a transpiling C engine. Java is unlikely to be the best choice.
In the era of LLM assistants like Claude Code, any engineer can write frontend code using popular stacks like React and TypeScript. This use case is when those tools shine.
I started with Applets in 1996, moving from Borland/Turbo C to Java. The Applet UI was never as smooth and rich as the OS-native stuff such as Windows GUI apps. But it was a great developement that brought applications to the web. IE+DHTML with a massive DOM API and VBScript+ASP took over soon, from 1997, to produce HTML-native interactive experience. People wrote ActiveX code to handle button clicks.
Servlets on the server-side survived a bit longer than applets, by evolving into JSP.
Compose multiplatform is the spiritual successor to JVM in the browser. Compiles to wasm, modern api, great developer experience. It's kotlin so not java, but easy for java developers to learn.
This is an interesting project and it's always neat to see things that are able to compile down to WASM for running in the browser. However, looking through the docs for Flavour and this feels like it would get very painful very quickly trying to write anything of substance.
> post your applet on a web page, and anyone on the planet could run it instantly
"Instant" is a strange choice of words to describe JVM startup performance. I recall the UX of encountering an applet involving watching a Java splash screen while the browser is frozen.
What’s funny about the “death of applets” is that it highlights a pattern we keep seeing: the browser killed plugins… and then reinvented everything they enabled, but properly this time.
TeaVM and similar toolchains show that the original idea behind applets wasn’t wrong — the implementation model was. Moving Java to JS/WASM with tree-shaking, minification, and real browser APIs gives you all the benefits without the security nightmare.
The interesting takeaway isn’t nostalgia for applets, but how mature the web stack has become: the browser is finally the runtime applets always wanted.
> reinvented everything they enabled, but properly this time
"Properly"? I'm not convinced. Browsers have grown incredibly large and complex. Every plugin it replaced by JS-based APIs has become a security nightmare in almost exactly the same way as the plugin based approach. Browsers have a lot of features, but if they were implemented "properly", the user would have far more control than they do now. The cynic in me thinks that many of these features are mostly there to facilitate ad-tech and user tracking. From fingerprintable canvas to access to devices.
Wouldn't it make more sense to run/emulate JVM bytecode on WASM instead of compiling Java to WASM? It seems like that'd be a much easier task.
From a high level WASM and JVM byte code seems incredibly similar (though I'm sure the containerizing and IO are radically different). I never really understood why WASM wasn't some JVM subset/extension.
Not an expert at all in this, so genuinely curious to hear from someone who understands this space well
+1 TeaVM is crazily good. Comparing to GWT it has faster build time and better exports to javascript. I've built so many games using libGDX + TeaVM and quite happy with the workflow and results.
This history of Java in the browser skips over GWT (which compiles to JavaScript) for some reason. Its heyday was roughly 2006-2012. The open source project still does occasional releases.
23 comments
[ 2.6 ms ] story [ 51.6 ms ] threadThat's one way to say it. The more common way was that users got tired of crappy plugins crashing their browsers, and browser devs got tired of endless complaints from their users.
It wasn't "politics" of any sort that made browsers sandbox everything. It was the insane number of crashes, out-of-memories, pegged CPUs, and security vulnerabilities that pushed things over the edge. You can only sit through so many dozens of Adobe 0-days before it starts to grate.
Adobe had big plans on the Ipod supporting Flash and that announcement all but killed their Flash division.
Yes, Adobe supported Flash for years after that, but it was more of a life support thing and not active development. They saw the writing on the wall and knew that for flash to survive, it had to survive in a mobile world.
With the decreased support of flash, the other browser devs simply followed suit and killed off a route for something like Flash running in a browser.
One of the first things I used to install on all my computers (laptops and desktops alike) was "block Flash until clicked" add-on.
I remember a few decades ago somebody saying the JVM was incredible technology, and as a user and programmer I still have zero clue what the hell they could have been thinking was good about the JVM.
I hear that now, decades into Java, they have figured out how to launch a program without slowing a computer down for 10+ seconds, but I'll be damned if I find out. There are still so many rough edges that they never even bothered to try to fix about launching a .jar with classpath dependencies. What a mess!
Running one packaged program across every platform. Write once, run anywhere was Sun's slogan for Java. (Though oftentimes ended up being debug anywhere.) As for the slow start part, programs can either be often-launched short-running or seldom-launched forever-running. Assume because enterprise software falls to the later part (and runtime performance > startup time + memory use), focus was there.
Feels like you are still living in year 2010 ?
In the era of LLM assistants like Claude Code, any engineer can write frontend code using popular stacks like React and TypeScript. This use case is when those tools shine.
Servlets on the server-side survived a bit longer than applets, by evolving into JSP.
"Instant" is a strange choice of words to describe JVM startup performance. I recall the UX of encountering an applet involving watching a Java splash screen while the browser is frozen.
TeaVM and similar toolchains show that the original idea behind applets wasn’t wrong — the implementation model was. Moving Java to JS/WASM with tree-shaking, minification, and real browser APIs gives you all the benefits without the security nightmare.
The interesting takeaway isn’t nostalgia for applets, but how mature the web stack has become: the browser is finally the runtime applets always wanted.
"Properly"? I'm not convinced. Browsers have grown incredibly large and complex. Every plugin it replaced by JS-based APIs has become a security nightmare in almost exactly the same way as the plugin based approach. Browsers have a lot of features, but if they were implemented "properly", the user would have far more control than they do now. The cynic in me thinks that many of these features are mostly there to facilitate ad-tech and user tracking. From fingerprintable canvas to access to devices.
Says that like it's a good thing.
From a high level WASM and JVM byte code seems incredibly similar (though I'm sure the containerizing and IO are radically different). I never really understood why WASM wasn't some JVM subset/extension.
Not an expert at all in this, so genuinely curious to hear from someone who understands this space well
Here's one of many: https://ookigame.com/game/flappy-bug/
https://en.wikipedia.org/wiki/Google_Web_Toolkit