Correct me if I&#x27;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.

The &quot;walled gardens&quot; 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&#x27;s blessing can gain access. AdoptOpenJDK was only granted access after they stopped distributing another Java runtime, OpenJ9.

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 &#x27;mobile&#x27; 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.

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.

&gt; banks to stop using it for online banking appsI never understood why so many banks flocked to building their online banking in applets when it wasn&#x27;t like you needed anything more advanced than HTML to view balances and make transactions.

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&#x2F;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.

Even Flash wasn&#x27;t as bad as Java applets, and that&#x27;s saying something.

Yeah, a totally mind boggling statement, almost completely void of reality. I wasn&#x27;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&#x27;t have to deal with any of that anymore.

That is almost entirely backwards.&gt; 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.&gt; 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.&gt; 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.&gt; 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?&gt; iPhone users stopped complainingIt 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.&gt; 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.&gt; Adobe was in a unique position to dominate the apps era, but they failed spectacularly.That much is true.&gt; 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?

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.

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&#x2F;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.

Don’t worry, they’re trying to sneak back in with WASM and drawing everything to canvas.

Applets also had no view-source.Spiritually the web ought to be more than an application development platform. We haven&#x27;t been doing great about that (with heavily compiled js bundles), but there&#x27;s still a lot of extensions that many users take for granted. I&#x27;m using a continual wordcount extension (50 words so far), and Dark Reader right now.Applet&#x27;s are the native app paradigm, where what the app-makers writes is what you get, never a drop more. It&#x27;s not great. The internet, the land of protocols, deserved better. Is so interesting because it is better.

I don&#x27;t think Safari mattered much. Java was still used for things that wouldn&#x27;t work on phones without massive redesigns anyway.I doubt you&#x27;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&#x2F;Java&#x2F;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.

I would attribute this much more to Mobile Safari saying &quot;no&quot;, which killed off plugins, especially Flash. Java Applets were essentially slow Flash from a user&#x27;s perspective.

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 &quot;block Flash until clicked&quot; add-on.

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.

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.

Yes I’m sure jobs went on stage calling out flash as the main source of Safari crashes because of Microsoft’s Java plugin.

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 &quot;applet crashes browser line, god riddance&quot; lineBut it was deliberate action by microsoft.So yeah 100% politics because without a court document in modern society we cannot call this anything else.

&gt; In the 2000&#x27;s, politics interfered and browser vendors removed plug-in support, instead preferring their own walled gardens and restricted sandboxesThat&#x27;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&#x27;t &quot;politics&quot; 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.

Mostly agreed that Java, warts and all, has gotten better, and will stick around. It&#x27;s the new COBOL, for better or worse. (I still wouldn&#x27;t want to use it voluntarily, but if someone pays me enough money, sure.)However:&gt; 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&#x27;s fine. Many of these transactions are offsetting, and that it&#x27;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&#x27;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.)

There&#x27;s zero sarcasm in my comment.The JVM is quite different from Java language features or Scala language features. I&#x27;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&#x27;s weird, but usable. The poor engineering around the JVM for many use cases? That&#x27;s a blocker for me, and where are the alternatives in implementation that don&#x27;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&#x27;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&#x27;s low-barrier-to-entry is quite distinct from the weaknesses of the JVM...

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&#x27;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.

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.

I guess in the era of SSDs (vs. spinning disks) and multi-GHz cores, the startup really isn&#x27;t a big issue anymore?I wonder how long Teams or Slack would take to launch when it&#x27;s on a 5400rpm disk on a 2000 era computer...

So your lack of technical knowledge or curiosity means Java wasn&#x27;t incredible? That&#x27;s certainly... a take. I&#x27;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&#x27;t know I like to learn - not just dismiss it. FYI, your .jar complaint is almost a decade out of date.

Of course, eliminating buffer overflows is orthogonal to using a virtual machine.

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&#x2F;C++ in the 90s.You got a buffer overflow safe language without compromise of speed. After it has been loaded, of course. But that&#x27;s why Java had such a tremendous effect in Web services where the load times are negligible to the run time.

&gt; 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 ?

&gt;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&#x27;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 &gt; startup time + memory use), focus was there.

Java wasn&#x27;t that bad for crappy 2D adventure games, but for the rest it was atrocious. Even TCL&#x2F;Tk looked faster with AMSN than trying to use Java based software which was like trying to run Gnome 4 under 1GB of RAM.

We were there. It still was atrociously slow compared to most TCL&#x2F;Tk stuff I&#x27;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.

Yeah, I&#x27;m going to re-learn Java just to spite the guy.

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... ?

And it hogs all your RAM or runs out of heap space, and online help says to pass more -Xmxwhatever flags that flip it between those two.

The only thing worse than launching the JVM from the command line, with it&#x27;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&#x27;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!

The alternatives to Java were just as bad. Flash and friends were fast but couldn&#x27;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.

&gt; post your applet on a web page, and anyone on the planet could run it instantly&quot;Instant&quot; 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.

The article literally links to a frontend that does just that, run the JVM on top of WASM. It performs fine: <a href="https:&#x2F;&#x2F;teavm.org&#x2F;gallery.html" rel="nofollow">https:&#x2F;&#x2F;teavm.org&#x2F;gallery.html</a>I&#x27;m not sure if I&#x27;d use it for a website or anything, but if my goal was to embed a simulation or complex widget, I wouldn&#x27;t ignore it as an option.

&gt; 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&#x27;s messy world.Multiple people can work on different things in the Java ecosystem.Compiling Rust to WASM doesn&#x27;t really distract anyone from compiling Rust to x86 or ARM, either.

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&#x27;s messy world.

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.

Browsers only support OpenGL ES so only if your shaders use any OpenGL specific features you have to rewrite. Otherwise, it&#x27;s just plain simple to export to both desktop and browser targets.

Do you have to rewrite GLSL shaders when migrating a game from desktop to browser?

+1 TeaVM is crazily good. Comparing to GWT it has faster build time and better exports to javascript. I&#x27;ve built so many games using libGDX + TeaVM and quite happy with the workflow and results.Here&#x27;s one of many: <a href="https:&#x2F;&#x2F;ookigame.com&#x2F;game&#x2F;flappy-bug&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ookigame.com&#x2F;game&#x2F;flappy-bug&#x2F;</a>

I started with Applets in 1996, moving from Borland&#x2F;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.

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.<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Google_Web_Toolkit" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Google_Web_Toolkit</a>

&gt; great developer experienceCompared to Java, maybe.It is a far cry from modern frontend development with vite.

Compose multiplatform is the spiritual successor to JVM in the browser. Compiles to wasm, modern api, great developer experience. It&#x27;s kotlin so not java, but easy for java developers to learn.

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.

Wouldn&#x27;t it make more sense to run&#x2F;emulate JVM bytecode on WASM instead of compiling Java to WASM? It seems like that&#x27;d be a much easier task.From a high level WASM and JVM byte code seems incredibly similar (though I&#x27;m sure the containerizing and IO are radically different). I never really understood why WASM wasn&#x27;t some JVM subset&#x2F;extension.Not an expert at all in this, so genuinely curious to hear from someone who understands this space well

This is an interesting project and it&#x27;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.

I&#x27;ve been using TeaVM for a while now, and it&#x27;s pretty great.

URL looks like your average java class AppletsGoneButJavaInTheBrowserBetterThanEverFactory

&gt;shrink the generated code and obfuscate the intent, to complicate reverse-engineeringSays that like it&#x27;s a good thing.

Good riddance: I guess Java is on a purge right now. First public static void main, now this unused mess. Its good for the ecosystem.

&gt; reinvented everything they enabled, but properly this time&quot;Properly&quot;? I&#x27;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 &quot;properly&quot;, 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.

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&#x2F;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.