> 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.
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.
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.
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.
Flash is still a big loss imho, the ecosystem of games, movies and demonstration thingies was amazing and they were accessible to create by many. Unlike Java applets that slowed the main browser UI thread to a crawl if they didn't load they usually didn't), Flash didn't have such slowdowns.
One exception is early 2000s Runescape: that was Java in browser but always loaded, no gray screen and hanging browser. They knew what they were doing.
Many of the old games and movies still play back well with Ruffle installed (https://ruffle.rs/). Newgrounds embeds it by default for old interactive flash media that they couldn't convert directly to video.
It's not a perfect fit, but it works. The speed of Ruffle loading on a page is similar to that of Flash initializing, so you can arguably still make flash websites and animations to get the old look and feel if you stick to the Ruffle compatibility range. The half-to-one-second page freeze that was the norm now feels wrong, though, so maybe it's not the best idea to put Flash components everywhere like we used to do.
Runescape proved that Java could be a pretty decent system, but so many inexperienced/bad Java developers killed the ecosystem. The same is true on the backend, where Java still suffers from the reputation the Java 7 monolithic mega projects left behind.
It's good that we have the runtime to run old Flash games. What we lost is an extremely easy environment for authoring/creating them. Nothing has come even close since Flash. Not just game, but any kind of interactions and animations on the web.
I think perhaps what was lost is mostly this: Macromedia. They had a knack for making content creation simple. Flash was just one of the results of this: It let people create seemingly-performant, potentially-interactive content that ran almost universally on the end-user computers of the time -- and do it with relative ease because the creation tools existed and were approachable.
Macromedia also provided direction, focus, and marketing; more of the things that allowed Flash to reach saturation.
Someone could certainly come up with an open JS stack that accomplishes some of the same things in a browser on a modern pocket supercomputer. And countless people certainly have.
But without forces like marketing to drive cohesion, simplicity, and adoption then none of them can reach similar saturation.
In my experience, most of the more important Java-on-the-web stuff was Java Web Start as opposed to applets. And Java Web Start was all kinds of bad. About the only remotely good thing I could say is that it has a sandbox. Which protected no one from anything, by design, because it was the app’s choice whether to use it. And Web Start apps also often included native code, too, so they weren’t even portable.
So much JWS PTSD. Industrial automation got a giant dose of it and those things somehow weren’t even portable to different versions of internet explorer.
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.
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.
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.
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.
Amusingly, we see the repeat of this in "desktop" apps that are just web technologies in a browser, wasting CPU time and RAM for "ease" of development. (I don't think it's easier at all - a mess of JS callbacks makes it difficult to see the initiator of anything).
> Amusingly, we see the repeat of this in "desktop" apps that are just web technologies in a browser, wasting CPU time and RAM for "ease" of development.
Web is chosen because it is the fastest way to hit all platforms, not because it's a skill issue.
> a mess of JS callbacks makes it difficult to see the initiator of anything
Async/await is available in most browsers since 2017, what year are you from?
I think the initial idea of being the fast to hit all platforms was the idea, but this has meant a lack of skill in developers who don't know about each platform, so you end up with a mess of apps that attempt to (badly) replicate native elements like menus.
You are right about async/await. I am old! (But I still find the development of software in a large JS system unmanageable versus old C++ development approaches).
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.
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.
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.
> 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?
> 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.
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
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.
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.
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.
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.
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.
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.
NPAPI's death in non-IE-browsers started around 2015. Jobs announcing mobile Safari without Flash was 2010. Unfortunately, ActiveX still works to this very day.
Chrome built up a whole new PPAPI to support reasonably fast Flash support after the Jobs announcement. Microsoft launched a major release of Silverlight long after Jobs' speech, but Silverlight (rightfully) died with Windows Phone, which it was the main UI platform for around its practical death. Had Microsoft managed to launch a decent mobile operating system, we'd probably still be running Silverlight in some fashion today. Even still, Silverlight lasted well until 2021 before Silverlight actually fell out of support.
Jobs may have had a hand in the death of Flash websites, but when it came to Java Applets/Silverlight, the decision had little impact. That plugin model was slowly dying on its own already.
There was a Flash runtime on Android. It was terrible. Java applets were already dead anyway, outside of professional contexts, which are not relevant on phones anyway.
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.
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).
With v-dom and bundles, we have lost a lot of the societal wins of view-source already. Extensions still work but user agency is more limited.
The view you are saying here is one that seems resoundingly common. Is what I heard from Flutter and flutter-web: my experience as a dve is what matters. What I can make is what matters.
That's true, sure! But there's a balance. Society matters too. What agency users have, what their user agency allows them to do, how they can circuit bend your website for themselves also matters. How we judge the scales here is a factor.
I am so so excited for wasm. Particularly wasm-components, where there is more than a huge mega bundle of compile code, where there are intelligible code boundaries and calls across modules. That, I want to hope will be a semi legibile WASM. But a lot of wasm today feels like it really slides back down the ladder into this rebuffing form of development that doesn't recognize any of how the web was better because it was more than the synthetic product it created, how the web was better for it's protocols, legibility, and user agency. I hope we don't slide back into a new Flash or Applet era, where the user & legibility & agency are given no regard, where a developer egocentricity is the only guiding principle.
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.
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 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.
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.)
> 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.
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...
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.
> 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.
> 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.
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.
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.
You can prevent buffer overflows even when you don't use a VM. Eg it's perfectly legal for your C compiler to insert checks. But there are also languages like Rust or Haskell that demand an absence of buffer overflows.
You can design a VM that still allows for buffer overflows. Eg you can compile C via the low-level-virtual-machine, and still get buffer overflows.
Any combination of VM (Yes/No) and buffer-overflows (Yes/No) is possible.
I agree that using a VM is one possible way to prevent buffer overflows.
>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.
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.
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... ?
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.
> 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.
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.
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.
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.
Takes a few seconds longer to load because it loads all of Java Spring, but it still performs just fine on my phone (though the lack of on screen keyboard activation makes it rather unfortunate for use in modern web apps).
> 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.
+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.
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.
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.
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.
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
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.
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.
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.
> 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.
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.
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.
ActiveX was hell for security.
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.
Flash is still a big loss imho, the ecosystem of games, movies and demonstration thingies was amazing and they were accessible to create by many. Unlike Java applets that slowed the main browser UI thread to a crawl if they didn't load they usually didn't), Flash didn't have such slowdowns.
One exception is early 2000s Runescape: that was Java in browser but always loaded, no gray screen and hanging browser. They knew what they were doing.
Many of the old games and movies still play back well with Ruffle installed (https://ruffle.rs/). Newgrounds embeds it by default for old interactive flash media that they couldn't convert directly to video.
It's not a perfect fit, but it works. The speed of Ruffle loading on a page is similar to that of Flash initializing, so you can arguably still make flash websites and animations to get the old look and feel if you stick to the Ruffle compatibility range. The half-to-one-second page freeze that was the norm now feels wrong, though, so maybe it's not the best idea to put Flash components everywhere like we used to do.
Runescape proved that Java could be a pretty decent system, but so many inexperienced/bad Java developers killed the ecosystem. The same is true on the backend, where Java still suffers from the reputation the Java 7 monolithic mega projects left behind.
It's good that we have the runtime to run old Flash games. What we lost is an extremely easy environment for authoring/creating them. Nothing has come even close since Flash. Not just game, but any kind of interactions and animations on the web.
Where did the tools go?
Can a person not run Flash authoring tools with an era-appropriate operating system in a VM or something?
Having to run it in a VM already makes it less approachable
That's the only way I guess. What I meant, with the death of Flash, nothing appeared to offer the same tools for any other web technology
I think perhaps what was lost is mostly this: Macromedia. They had a knack for making content creation simple. Flash was just one of the results of this: It let people create seemingly-performant, potentially-interactive content that ran almost universally on the end-user computers of the time -- and do it with relative ease because the creation tools existed and were approachable.
Macromedia also provided direction, focus, and marketing; more of the things that allowed Flash to reach saturation.
Someone could certainly come up with an open JS stack that accomplishes some of the same things in a browser on a modern pocket supercomputer. And countless people certainly have.
But without forces like marketing to drive cohesion, simplicity, and adoption then none of them can reach similar saturation.
In my experience, most of the more important Java-on-the-web stuff was Java Web Start as opposed to applets. And Java Web Start was all kinds of bad. About the only remotely good thing I could say is that it has a sandbox. Which protected no one from anything, by design, because it was the app’s choice whether to use it. And Web Start apps also often included native code, too, so they weren’t even portable.
So much JWS PTSD. Industrial automation got a giant dose of it and those things somehow weren’t even portable to different versions of internet explorer.
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.
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.
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.
> 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.
Because they’ve hired a bunch of Java devs that don’t know anything outside of Java?
Amusingly, we see the repeat of this in "desktop" apps that are just web technologies in a browser, wasting CPU time and RAM for "ease" of development. (I don't think it's easier at all - a mess of JS callbacks makes it difficult to see the initiator of anything).
> Amusingly, we see the repeat of this in "desktop" apps that are just web technologies in a browser, wasting CPU time and RAM for "ease" of development.
Web is chosen because it is the fastest way to hit all platforms, not because it's a skill issue.
> a mess of JS callbacks makes it difficult to see the initiator of anything
Async/await is available in most browsers since 2017, what year are you from?
I think the initial idea of being the fast to hit all platforms was the idea, but this has meant a lack of skill in developers who don't know about each platform, so you end up with a mess of apps that attempt to (badly) replicate native elements like menus.
You are right about async/await. I am old! (But I still find the development of software in a large JS system unmanageable versus old C++ development approaches).
Java Servlets and JSPs output HTML. I've been building a blog with them for over 15 years.
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.
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.
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.
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?
> 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.
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
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.
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.
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.
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.
Even Flash wasn't as bad as Java applets, and that's saying something.
Flash was great when it came to experiences. Ignoring melting CPU, crashes, loading times.
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.
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.
> 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.
>then everyone else followed suit
NPAPI's death in non-IE-browsers started around 2015. Jobs announcing mobile Safari without Flash was 2010. Unfortunately, ActiveX still works to this very day.
Chrome built up a whole new PPAPI to support reasonably fast Flash support after the Jobs announcement. Microsoft launched a major release of Silverlight long after Jobs' speech, but Silverlight (rightfully) died with Windows Phone, which it was the main UI platform for around its practical death. Had Microsoft managed to launch a decent mobile operating system, we'd probably still be running Silverlight in some fashion today. Even still, Silverlight lasted well until 2021 before Silverlight actually fell out of support.
Jobs may have had a hand in the death of Flash websites, but when it came to Java Applets/Silverlight, the decision had little impact. That plugin model was slowly dying on its own already.
> then everyone else followed suit
There was a Flash runtime on Android. It was terrible. Java applets were already dead anyway, outside of professional contexts, which are not relevant on phones anyway.
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.
Don’t worry, they’re trying to sneak back in with WASM and drawing everything to canvas.
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).
With v-dom and bundles, we have lost a lot of the societal wins of view-source already. Extensions still work but user agency is more limited.
The view you are saying here is one that seems resoundingly common. Is what I heard from Flutter and flutter-web: my experience as a dve is what matters. What I can make is what matters.
That's true, sure! But there's a balance. Society matters too. What agency users have, what their user agency allows them to do, how they can circuit bend your website for themselves also matters. How we judge the scales here is a factor.
I am so so excited for wasm. Particularly wasm-components, where there is more than a huge mega bundle of compile code, where there are intelligible code boundaries and calls across modules. That, I want to hope will be a semi legibile WASM. But a lot of wasm today feels like it really slides back down the ladder into this rebuffing form of development that doesn't recognize any of how the web was better because it was more than the synthetic product it created, how the web was better for it's protocols, legibility, and user agency. I hope we don't slide back into a new Flash or Applet era, where the user & legibility & agency are given no regard, where a developer egocentricity is the only guiding principle.
I wish there was a setting in major browsers to disable WASM or at least ask to enable per site
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.
Yes I’m sure jobs went on stage calling out flash as the main source of Safari crashes because of Microsoft’s Java plugin.
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 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.
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.)
> 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.
You could easily say the same about C/C++, as the operating systems and most databases are written in the language(s).
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...
> 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.
> Having a register machine doesn't seem very useful...
Requires fewer instructions, so potentially faster evaluation, which is good for short-lived programs that ends before the JIT kicks in.
Stack machines requires less space per instruction, however, which reduces the size of the program (faster to load).
> 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.
> 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.
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...
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.
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.
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.
Of course, eliminating buffer overflows is orthogonal to using a virtual machine.
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.
No, it's not? Using a VM is one way of preventing buffer overflows, it's not orthogonal.
You can prevent buffer overflows even when you don't use a VM. Eg it's perfectly legal for your C compiler to insert checks. But there are also languages like Rust or Haskell that demand an absence of buffer overflows.
You can design a VM that still allows for buffer overflows. Eg you can compile C via the low-level-virtual-machine, and still get buffer overflows.
Any combination of VM (Yes/No) and buffer-overflows (Yes/No) is possible.
I agree that using a VM is one possible way to prevent buffer overflows.
> 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 ?
>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.
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.
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.
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... ?
Yeah, I'm going to re-learn Java just to spite the guy.
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.
> 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.
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.
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.
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.
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.
It doesn't run the JVM. It's an ahead-of-time compiler that converts Java bytecode to wasm.
Oh, if you want a full fat JVM, then you want CheerpJ https://cheerpjdemos.leaningtech.com/SwingDemo.html#demo
Takes a few seconds longer to load because it loads all of Java Spring, but it still performs just fine on my phone (though the lack of on screen keyboard activation makes it rather unfortunate for use in modern web apps).
> 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.
+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/
Do you have to rewrite GLSL shaders when migrating a game from desktop to browser?
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.
Thanks. What is your take on building multiplayer game with TeaVM + libgdx? (Assuming the server is hosted off-browser)
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.
https://en.wikipedia.org/wiki/Google_Web_Toolkit
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.
> great developer experience
Compared to Java, maybe.
It is a far cry from modern frontend development with vite.
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
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.
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.
I've been using TeaVM for a while now, and it's pretty great.
URL looks like your average java class AppletsGoneButJavaInTheBrowserBetterThanEverFactory
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.
>shrink the generated code and obfuscate the intent, to complicate reverse-engineering
Says that like it's a good thing.
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.
[flagged]