Applets are officially gone, but Java in the browser is better
100 comments
·December 8, 2025kstrauser
maxloh
The "walled gardens" he referred to are in fact based on open standards and open source, while the Applet runtime is not.
Not all of Java is open source. The TCK, the testing suite for standard compliance, for instance, is proprietary, and only organizations with Oracle's blessing can gain access. AdoptOpenJDK was only granted access after they stopped distributing another Java runtime, OpenJ9.
exDM69
Correct me if I'm wrong but during this timeframe (circa 2005), Java was not open source at all. OpenJDK was announced in 2006 and first release was 2008, by which time the days Java in the browser were more or less over.
anthk
ActiveX was hell for security.
jeroenhd
ActiveX was its own special kind of terrible for many reasons, but so were Java, Flash, and Silverlight. At least ActiveX didn't hide the fact you were about to grant arbitrary code execution to a website, because you might as well have assumed that the second these plugins were loaded.
The only advantage to Java applets I can think of is that they had the advantage of freezing the browser so it could no longer be hacked.
The Java applet system was designed better than ActiveX but in practice I've always found it to be so much worse of an end user experience. This probably had to do with the fact most ActiveX components were rather small integrations rather than (badly fitted) full-page UIs.
exDM69
Exactly.
Java was so buggy and had so many security issues about 20 years ago that my local authorities gave a security advisory to not install it at all in end user/home computers. That finally forced the hand of some banks to stop using it for online banking apps.
Flash also had a long run of security issues.
Gravityloss
In the 2000s, my bank was acquired by some bigger bank from another country. Their long standing, well working and fast banking application was replaced with a very dysfunctional Java applet thing. I was using Linux at the time and IIRC it either worked barely, or then not at all. I phoned the bank, and they told about a secret alternate 'mobile' url, that had a proper working service. I used that for a while before ultimately switching to another bank. The bank sent apology letters to customers and waived some fees also as they saw many of them leave. It made me really wake up that to the fact if the company can do these visible level blunders, what else is going on there, and also, how the customer is in such a vulnerable position.
On the other hand, NASA in the past had some really great Java applets to play with some technical concept and get updated diagrams, animations and graphs etc.
bigfatkitten
I worked for a large financial institution in the early 2010s.
They ran Windows XP, IE 8, and they stuck with a 3-4 year old JRE to support one piece of shit line of business app that was used only by about 100 (out of 50,000) users internally.
That institution had endpoints popped by drive-by exploit kits dropping banking trojans like Zeus daily.
cube00
> banks to stop using it for online banking apps
I never understood why so many banks flocked to building their online banking in applets when it wasn't like you needed anything more advanced than HTML to view balances and make transactions.
wiseowise
Because they’ve hired a bunch of Java devs that don’t know anything outside of Java?
elric
I'm getting the impression you're conveniently ignoring how piss poor HTML/AJAX/JS capabilities were back then, or even how slow internet speeds were.
Applets could do things that JS could not. Some bank applets did client side crypto with keys that were on the device. Good luck doing that in JS back then. My bank's applet could cope with connection losses so I could queue a payment while dialup did it's thing.
im3w1l
Java did many things very right. It's a really fast language. It's memory safe. It could run anywhere. It had well-thought out namespacing at a time where namespacing was a concept most people barely knew they needed it. It had an advanced security model.
It was a very reasonable bet at the time imo.
locallost
Yeah, a totally mind boggling statement, almost completely void of reality. I wasn't even tired of the crashes, it was just a totally awful experience of using them in every way. They took forever to load, were clunky to use and even just downright ugly because the UI had nothing to do with what you usually got to use, and was a lot worse. The idea was good on paper, but the implementation sucked.
Everyone, well almost everyone apparently, was relieved we didn't have to deal with any of that anymore.
ozgung
For Flash vs iPhone case, it was indeed mostly politics. People were using Flash and other plugins in websites because there were no other alternative, say to add a video player or an animation. iPhone was released in 2007 and app store in 2008. iPhone and iPad did not support then popular Flash in their browsers. Web experience was limited and broken. HTML5 was first announced in 2008 but would be under development for many years. Not standardized yet and browser support was limited. Web apps were not a thing without Flash. Only alternative for the users was the App Store, the ultimate walled garden. There were native apps for everything, even for the simplest things. Flash ecosystem was the biggest competitor and threat for the App Store at that moment. Finally in 2010 Steve Jobs addressed the Flash issue and openly declared they will never support it. iPhone users stopped complaining and in 2011 Adobe stopped the development of mobile plugins.
Adobe was in a unique position to dominate the apps era, but they failed spectacularly. They could have implemented payment/monetization options for their ecosystem, to build their own walled garden. Plugins were slow but this was mostly due to hardware at the time. This changed rapidly in the following years, but without control of the hardware, they had already lost the market.
kergonath
That is almost entirely backwards.
> For Flash vs iPhone case, it was indeed mostly politics.
It was politics in the sense that Flash was one of the worst cause of instability in Safari on OS X, and was terrible at managing performance and a big draw on battery life, all of which were deal breakers on the iPhone. This is fairly well documented.
> iPhone was released in 2007 and app store in 2008. iPhone and iPad did not support then popular Flash in their browsers.
There were very good reasons for that.
> Web apps were not a thing without Flash.
That is entirely, demonstrably false. There were plenty of web apps, and they were actually the recommended (and indeed the only one) way of getting apps onto iPhones before they scrambled to release the App Store.
> Flash ecosystem was the biggest competitor and threat for the App Store at that moment.
How could it be a competitor if it was not supported?
> iPhone users stopped complaining
It was not iPhones users who were complaining. It was Android users explaining us how prehistoric iPhones were for not supporting Flash. We were perfectly happy with our apps.
> and in 2011 Adobe stopped the development of mobile plugins.
Yeah. Without ever leaving beta status. Because it was unstable, had terrible performances, and drained batteries. Just what Jobs claimed as reasons not to support it.
> Adobe was in a unique position to dominate the apps era, but they failed spectacularly.
That much is true.
> Plugins were slow but this was mostly due to hardware at the time.
Then, how could native apps have much better performance on the same hardware, on both Android and iOS?
kirb
> Then, how could native apps have much better performance on the same hardware, on both Android and iOS?
Web engines were honestly not great back then. WebKit was ok but JavaScriptCore was very slow, and of course that’s what iOS, Android, and BB10 were all running on that slow hardware. I have distinct (bad) memories that even “GPU-accelerated” CSS animations were barely 15fps, while native apps reliably got 60fps unless they really messed up. That’s on top of the infamous 300ms issue, where every tap took 300ms to fire off because it was waiting to see if you were trying to double-tap.
So I really think some of the blame is still shared with Apple, although it’s hard to say if that’s because of any malicious intent to prop up the App Store, or just because they were under pressure to build out the iOS platform that there wasn’t enough time to optimise. I suspect it was both.
butvacuum
I will never forget the hubub around the discovery that everything you typed on android went to a root shell. "What should I do?"... "reboot" phone reboots
kstrauser
The best think Jobs ever did for tech was forcing the whole industry to advance HTML to where it could replace Flash, and killing the market for proprietary browser content plugins. I don’t want to imagine what the web would be like today if Flash had won, and the whole web was a loader for one closed-source, junky plugin.
jauntywundrkind
Applets also had no view-source.
Spiritually the web ought to be more than an application development platform. We haven't been doing great about that (with heavily compiled js bundles), but there's still a lot of extensions that many users take for granted. I'm using a continual wordcount extension (50 words so far), and Dark Reader right now.
Applet's are the native app paradigm, where what the app-makers writes is what you get, never a drop more. It's not great. The internet, the land of protocols, deserved better. Is so interesting because it is better.
wiseowise
Don’t worry, they’re trying to sneak back in with WASM and drawing everything to canvas.
MarsIronPI
At least with WASM I'm not stuck using Javascript whether I like it or not. Yes, transpiling to Javascript is a thing, but it's not too much better, since transpiled code isn't much more readable than WASM (see also ClojureScript; CoffeScript isn't too bad though, but it's almost equivalent to JS).
zihotki
I wish there was a setting in major browsers to disable WASM or at least ask to enable per site
petesergeant
I would attribute this much more to Mobile Safari saying "no", which killed off plugins, especially Flash. Java Applets were essentially slow Flash from a user's perspective.
jeroenhd
I don't think Safari mattered much. Java was still used for things that wouldn't work on phones without massive redesigns anyway.
I doubt you'd have been able to bootstrap Runescape in any form, even rewritten in native code, on the first iPhone to support apps. Applets worked fine on desktops and tablets which was what they were designed for.
Browser vendors killed the API because when they looked at crashes, freezes, and performance opportunities, the Flash/Java/etc. API kept standing out. Multithreaded rendering became practical only after the old extension model was refactorerd and even then browsers were held down by the terrible plugin implementations they needed to work around.
masklinn
> I don't think Safari mattered much.
Apple was the first to publicly call out native plugins (jobs did so on stage) and outright refused to support them on iOS, then everyone else followed suit.
cogman10
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.
theamk
Makes sense, Flash was eating battery like crazy. And it was widely used in ads, so it would appear on all pages of the internet.
One of the first things I used to install on all my computers (laptops and desktops alike) was "block Flash until clicked" add-on.
musicale
Now no web browser can reliably block autoplaying video. :(
avereveard
It mostly was politics. Browser crashes and slowness were almost always traced down to microsoft own java plugin that strongarmed proper java plugin install out of the way every update and every now and then to be sure, with a semi compatible runtime and a classloarlder that insisted fronting the dow load of all resources.
It created so much uncertainty across the ecosystem even today people repeat the "applet crashes browser line, god riddance" line
But it was deliberate action by microsoft.
So yeah 100% politics because without a court document in modern society we cannot call this anything else.
sunaookami
No? Microsoft Java was discontinued in 2004, the crashes were infamous even way later in 2010. Flash was also notorious for crashing Firefox on YouTube. Not even mentioning the bad security of these plugins.
masklinn
Yes I’m sure jobs went on stage calling out flash as the main source of Safari crashes because of Microsoft’s Java plugin.
epistasis
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!
another_twist
I understand the sarcasm but this take is devoid of fact. Modern Java loads fast, Java 21 has pretty good functional programming featurez. The ecosystem churns out language level features at a pace and a budget that would put most large funded startups to shame.
Java is also the workhorse of the big data ecosystem and moves enough money either as product revenue or as transactions than most nations GDP. They didn't figure out startup times for 10+ years, they were busy dealing with Oracle and its messy management. I think it will simply continue to get better given that Java has endured through so many language fads. It has its ways to go but it will end up like SQL - here before we were alive and will be here when most of us are dead.
eru
Mostly agreed that Java, warts and all, has gotten better, and will stick around. It's the new COBOL, for better or worse. (I still wouldn't want to use it voluntarily, but if someone pays me enough money, sure.)
However:
> Java is also the workhorse of the big data ecosystem and moves enough money either as product revenue or as transactions than most nations GDP.
The global financial system moves so much money around that comparisons to GDP are a bit silly. Financial transactions dwarf GDP by so much that even a bit player of a technology will facilitate more transactions than global GDP.
(And that's fine. Many of these transactions are offsetting, and that it's a sign of an efficient market that the mispricings are so small that participants needs giant gross flows to profit from them.
Somewhat related: a single high capacity fire hose (at about 75kg of water per second) moves about the same number of electrons as you'd need to power the total US electricity consumption at 120V. Obviously, your fire hose also sprays plenty of pesky protons which completely offset the electrical current from the electrons.)
another_twist
> The global financial system moves so much money around that comparisons to GDP are a bit silly.
Agreed. I guess its comparing production capacity to distribution capacity. Distribution capacity will equal n_tx * tx_amt. Having said that, another metric to look at is how much of software infrastructure is built on Java. Simply adding AWS to this equation proves the value added by Java backed systems. Hard to say that about any other langauge. Also we can look at versatility, Java is used to write very large data processing systems, CDN networks, API servers and even widely used consumer apps (IntelliJ products). Its very hard to find any other language that has had an outsized impact across domains. Of course the counter being Linux written on C powers all of the internet. True but C doesnt have the cross domain impact that Java has had.
So I disagree with the assessment that Java is a terrible langauge performance or productivity wise or it wouldnt have had this impact.
epistasis
There's zero sarcasm in my comment.
The JVM is quite different from Java language features or Scala language features. I've written entire programs in JVM bytecode, without a compiler, and I see very little of value in it. A stack based machine? Why? Not a huge blocker, it's weird, but usable. The poor engineering around the JVM for many use cases? That's a blocker for me, and where are the alternatives in implementation that don't have the atrocious launch performance and interface for specifying class path and jars?
Java may be used a lot, but so is Windows. It's an accident of history, of early adoption and network effects, rather than being inherently good technology. Java, the language, made a very wide and broad swath of programmers productive, just as Windows lets a very wide and broad set of IT people run IT systems, without having to learn as much or know as much as they would need to with, say, Linux. But Java's low-barrier-to-entry is quite distinct from the weaknesses of the JVM...
writebetterc
> A stack based machine? Why?
The JVM being a stack-machine is probably the least controversial thing about it. Wasm, CPython and Emacs all also have a stack-based bytecode language. The value, of course, comes from having a generic machine that you can then compile down into whatever machine code you want. Having a register machine doesn't seem very useful, as it's completely unnecessary for the front-end compiler to minimize register usage (the backend compiler will do that for you).
Specifying classpath isn't fun, I agree with that. Launch performance isn't good, and is generally a consequence of its high degree of dynamicism and JIT compiler, though of course there are ways around that (Leyden).
> I've written entire programs in JVM bytecode, without a compiler, and I see very little of value in it
I agree, I also see very little value in manually writing JVM bytecode programs. However, compiling into the JVM classfile format? Pretty darn useful.
eru
> Java may be used a lot, but so is Windows. It's an accident of history, of early adoption and network effects, rather than being inherently good technology.
Going on a tangent: Windows is an interesting example to bring up, because the Windows versions everyone uses today have about as much to do with the 'accident of history / early adoption' versions that were based on DOS as using Wine on Linux has.
It would perhaps be like today's JVM being register based, when the first version were stack based.
I don't actually know how much the JVM has changed over time.
another_twist
> 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 see what you mean. In that case we can add Scala backed systems as well to the JVM balance sheet. If we simply look at the JVM and the systems it backs, there's very little evidence that it isnt a marvel of technology. It powers more impactful systems than few other technologies.
netsharc
I guess in the era of SSDs (vs. spinning disks) and multi-GHz cores, the startup really isn't a big issue anymore?
I wonder how long Teams or Slack would take to launch when it's on a 5400rpm disk on a 2000 era computer...
nrhrjrjrjtntbt
I remember my 2000 computer could play an mp3. But thats it. Your system is 100% utilized. No way it could even think about a modern gas guzzling app.
matsemann
So your lack of technical knowledge or curiosity means Java wasn't incredible? That's certainly... a take. I'm almost curious: why did you end up holding strong beliefs like these, instead of actually investigating? As a curious person, when I hear something I don't know I like to learn - not just dismiss it. FYI, your .jar complaint is almost a decade out of date.
bhaak
The JVM proved to the mainstream that a virtual machine good be as fast (sometimes even faster) than a compiled binary. Because of that it took a lot of the market share of C/C++ in the 90s.
You got a buffer overflow safe language without compromise of speed. After it has been loaded, of course. But that's why Java had such a tremendous effect in Web services where the load times are negligible to the run time.
eru
Of course, eliminating buffer overflows is orthogonal to using a virtual machine.
bhaak
You also got a language easier to use and learn than C/C++.
With universities almost immediately jumping to Java as an introductory language you got way more potential employees.
writebetterc
No, it's not? Using a VM is one way of preventing buffer overflows, it's not orthogonal.
lenkite
> There are still so many rough edges that they never even bothered to try to fix about launching a .jar with classpath dependencies.
Feels like you are still living in year 2010 ?
forgotpwd16
>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.
anthk
Java wasn't that bad for crappy 2D adventure games, but for the rest it was atrocious. Even TCL/Tk looked faster with AMSN than trying to use Java based software which was like trying to run Gnome 4 under 1GB of RAM.
kakacik
What the heck are you writing about, you clearly have no clue about last 2+ decades of Java or topic in general but felt the urgent need to emotionally vent off because... ?
anthk
We were there. It still was atrociously slow compared to most TCL/Tk stuff I've used. TCL and Tk improved a little on speed and it almost looks native on tons of software, meanwhile with Java if you have to run some biggie software on legacy machines you are doomed by watching the widgets redraw themselves in some cases.
And, on its Android cousin... pick any S60 based Symbian phone (or anything else)... and try telling us the same. The lag, the latency, the bullshit of Java we are suffering because, you know, for phone developers, switch from J2ME to another Java stack was pretty much an easy task, but hell for the user. Even Inferno would have been better if it were free and it had a mobile ecosystem developed for it.
bigbuppo
Yeah, I'm going to re-learn Java just to spite the guy.
ptx
> 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.
jeroenhd
The alternatives to Java were just as bad. Flash and friends were fast but couldn't do anything more complicated than animation for most of its life. In the Java heydays, you were doing either Java or custom ActiveX plugins, and both led to security popups galore and random browser freezes.
However, ActiveX usually required you to install components, while Java could just run first time.
jakozaur
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.
another_twist
Java running in the browser is unlikely as typescript has largely tamed the mess of Javascript. Java requires a JVM and shipping an entire JVM so its runs atop another VM is kinda redundant. Except if JVM itself gets compiled and cached as a WASM bundle and Java compilers start accept WASM-JVM as a target. That will just be distraction tbh, Java has its strength in large scale systems and it should just focus on those rather than get caught up in Frontend's messy world.
jeroenhd
The article literally links to a frontend that does just that, run the JVM on top of WASM. It performs fine: https://teavm.org/gallery.html
I'm not sure if I'd use it for a website or anything, but if my goal was to embed a simulation or complex widget, I wouldn't ignore it as an option.
bloppe
It doesn't run the JVM. It's an ahead-of-time compiler that converts Java bytecode to wasm.
eru
> That will just be distraction tbh, Java has its strength in large scale systems and it should just focus on those rather than get caught up in Frontend's messy world.
Multiple people can work on different things in the Java ecosystem.
Compiling Rust to WASM doesn't really distract anyone from compiling Rust to x86 or ARM, either.
rimmontrieu
+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.
Here's one of many: https://ookigame.com/game/flappy-bug/
iamcreasy
Do you have to rewrite GLSL shaders when migrating a game from desktop to browser?
rimmontrieu
Browsers only support OpenGL ES so only if your shaders use any OpenGL specific features you have to rewrite. Otherwise, it's just plain simple to export to both desktop and browser targets.
iamcreasy
Thanks. What is your take on building multiplayer game with TeaVM + libgdx? (Assuming the server is hosted off-browser)
zkmon
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.
skybrian
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.
grizzles
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.
wiseowise
> great developer experience
Compared to Java, maybe.
It is a far cry from modern frontend development with vite.
geokon
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
DarkNova6
From my understanding, this works for C# but is an ill-fit for Java. Java has simple bytecode with a powerful runtime to ensure all kinds of guarantees. C# focuses on compile-time checks with a more complex bytecode representation.
So instead you got TeaVM which is essentially a whole JVM in WASM.
ahmeni
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.
skerit
I've been using TeaVM for a while now, and it's pretty great.
tracerbulletx
URL looks like your average java class AppletsGoneButJavaInTheBrowserBetterThanEverFactory
> 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.