by kstrauser
8 subcomments
- > 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.
by epistasis
9 subcomments
- 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!
- > 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.
- 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.
by rimmontrieu
1 subcomments
- +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/
- 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.
- 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
- 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
- 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.
by tracerbulletx
0 subcomment
- URL looks like your average java class AppletsGoneButJavaInTheBrowserBetterThanEverFactory
- >shrink the generated code and obfuscate the intent, to complicate reverse-engineering
Says that like it's a good thing.
by another_twist
0 subcomment
- 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.
- 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.
Hacker News