[HN Gopher] Applets are officially gone, but Java in the browser...
___________________________________________________________________
Applets are officially gone, but Java in the browser is better
Author : pjmlp
Score : 61 points
Date : 2025-12-08 08:16 UTC (14 hours ago)
(HTM) web link (frequal.com)
(TXT) w3m dump (frequal.com)
| kstrauser wrote:
| > 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.
| exDM69 wrote:
| 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.
| cube00 wrote:
| > banks to stop using it for online banking apps
|
| I never understood why so many banks flocked to building
| their online banking in applets when it wasn't like you
| needed anything more advanced than HTML to view balances and
| make transactions.
| wiseowise wrote:
| Because they've hired a bunch of Java devs that don't know
| anything outside of Java?
| 72deluxe wrote:
| 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).
| wiseowise wrote:
| > 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?
| theandrewbailey wrote:
| Java Servlets and JSPs output HTML. I've been building a
| blog with them for over 15 years.
| elric wrote:
| 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.
| Gravityloss wrote:
| In the 2000s, my bank was acquired by some bigger bank from
| another country. Their long standing, well working and fast
| banking application was replaced with a very dysfunctional
| Java applet thing. I was using Linux at the time and IIRC it
| either worked barely, or then not at all. I phoned the bank,
| and they told about a secret alternate 'mobile' url, that had
| a proper working service. I used that for a while before
| ultimately switching to another bank. The bank sent apology
| letters to customers and waived some fees also as they saw
| many of them leave. It made me really wake up that to the
| fact if the company can do these visible level blunders, what
| else is going on there, and also, how the customer is in such
| a vulnerable position.
|
| On the other hand, NASA in the past had some really great
| Java applets to play with some technical concept and get
| updated diagrams, animations and graphs etc.
| bigfatkitten wrote:
| 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_.
| locallost wrote:
| 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.
| razakel wrote:
| Even Flash wasn't as bad as Java applets, and that's saying
| something.
| wiseowise wrote:
| Flash was great when it came to experiences. Ignoring
| melting CPU, crashes, loading times.
| maxloh wrote:
| 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.
| anthk wrote:
| ActiveX was hell for security.
| jeroenhd wrote:
| 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.
| Aardwolf wrote:
| 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.
| jeroenhd wrote:
| 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.
| troupo wrote:
| 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.
| ssl-3 wrote:
| Where did the tools go?
|
| Can a person not run Flash authoring tools with an era-
| appropriate operating system in a VM or something?
| amluto wrote:
| 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.
| insearchoflost wrote:
| 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.
| exDM69 wrote:
| 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.
| petesergeant wrote:
| I would attribute this much more to Mobile Safari saying "no",
| which killed off plugins, especially Flash. Java Applets were
| essentially slow Flash from a user's perspective.
| jeroenhd wrote:
| I don't think Safari mattered much. Java was still used for
| things that wouldn't work on phones without massive redesigns
| anyway.
|
| I doubt you'd have been able to bootstrap Runescape in any
| form, even rewritten in native code, on the first iPhone to
| support apps. Applets worked fine on desktops and tablets
| which was what they were designed for.
|
| Browser vendors killed the API because when they looked at
| crashes, freezes, and performance opportunities, the
| Flash/Java/etc. API kept standing out. Multithreaded
| rendering became practical only after the old extension model
| was refactorerd and even then browsers were held down by the
| terrible plugin implementations they needed to work around.
| masklinn wrote:
| > 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.
| jeroenhd wrote:
| >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.
| kergonath wrote:
| > 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.
| jauntywundrkind wrote:
| Applets also had no view-source.
|
| Spiritually the web _ought_ to be more than an application
| development platform. We haven 't been doing great about that
| (with heavily compiled js bundles), but there's still a lot of
| extensions that many users take for granted. I'm using a
| continual wordcount extension (50 words so far), and Dark
| Reader right now.
|
| Applet's are the native app paradigm, where what the app-makers
| writes is what you get, never a drop more. It's not great. The
| internet, the land of protocols, deserved better. Is so
| interesting because it is better.
| wiseowise wrote:
| Don't worry, they're trying to sneak back in with WASM and
| drawing everything to canvas.
| zihotki wrote:
| I wish there was a setting in major browsers to disable
| WASM or at least ask to enable per site
| MarsIronPI wrote:
| 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).
| avereveard wrote:
| 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.
| masklinn wrote:
| Yes I'm sure jobs went on stage calling out flash as the main
| source of Safari crashes because of Microsoft's Java plugin.
| ozgung wrote:
| For Flash vs iPhone case, it was indeed mostly politics. People
| were using Flash and other plugins in websites because there
| were no other alternative, say to add a video player or an
| animation. iPhone was released in 2007 and app store in 2008.
| iPhone and iPad did not support then popular Flash in their
| browsers. Web experience was limited and broken. HTML5 was
| first announced in 2008 but would be under development for many
| years. Not standardized yet and browser support was limited.
| Web apps were not a thing without Flash. Only alternative for
| the users was the App Store, the ultimate walled garden. There
| were native apps for everything, even for the simplest things.
| Flash ecosystem was the biggest competitor and threat for the
| App Store at that moment. Finally in 2010 Steve Jobs addressed
| the Flash issue and openly declared they will never support it.
| iPhone users stopped complaining and in 2011 Adobe stopped the
| development of mobile plugins.
|
| Adobe was in a unique position to dominate the apps era, but
| they failed spectacularly. They could have implemented
| payment/monetization options for their ecosystem, to build
| their own walled garden. Plugins were slow but this was mostly
| due to hardware at the time. This changed rapidly in the
| following years, but without control of the hardware, they had
| already lost the market.
| kergonath wrote:
| 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?
| kstrauser wrote:
| 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.
| cogman10 wrote:
| 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.
| epistasis wrote:
| 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!
| netsharc wrote:
| I guess in the era of SSDs (vs. spinning disks) and multi-GHz
| cores, the startup really isn't a big issue anymore?
|
| I wonder how long Teams or Slack would take to launch when it's
| on a 5400rpm disk on a 2000 era computer...
| nrhrjrjrjtntbt wrote:
| 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.
| kakacik wrote:
| What the heck are you writing about, you clearly have no clue
| about last 2+ decades of Java or topic in general but felt the
| urgent need to emotionally vent off because... ?
| anthk wrote:
| 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.
| another_twist wrote:
| 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.
| epistasis wrote:
| 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...
| eru wrote:
| > 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.
| writebetterc wrote:
| > 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.
| Skinney wrote:
| > 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).
| another_twist wrote:
| > 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.
| eru wrote:
| Mostly agreed that Java, warts and all, has gotten better,
| and will stick around. It's the new COBOL, for better or
| worse. (I still wouldn't want to use it voluntarily, but if
| someone pays me enough money, sure.)
|
| However:
|
| > Java is also the workhorse of the big data ecosystem and
| moves enough money either as product revenue or as
| transactions than most nations GDP.
|
| The global financial system moves so much money around that
| comparisons to GDP are a bit silly. Financial transactions
| dwarf GDP by so much that even a bit player of a technology
| will facilitate more transactions than global GDP.
|
| (And that's fine. Many of these transactions are offsetting,
| and that it's a sign of an efficient market that the
| mispricings are so small that participants needs giant gross
| flows to profit from them.
|
| Somewhat related: a single high capacity fire hose (at about
| 75kg of water per second) moves about the same number of
| electrons as you'd need to power the total US electricity
| consumption at 120V. Obviously, your fire hose also sprays
| plenty of pesky protons which completely offset the
| electrical current from the electrons.)
| another_twist wrote:
| > 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.
| Sardtok wrote:
| You could easily say the same about C/C++, as the
| operating systems and most databases are written in the
| language(s).
| anthk wrote:
| 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.
| bhaak wrote:
| The JVM proved to the mainstream that a virtual machine good be
| as fast (sometimes even faster) than a compiled binary. Because
| of that it took a lot of the market share of C/C++ in the 90s.
|
| You got a buffer overflow safe language without compromise of
| speed. After it has been loaded, of course. But that's why Java
| had such a tremendous effect in Web services where the load
| times are negligible to the run time.
| eru wrote:
| Of course, eliminating buffer overflows is orthogonal to
| using a virtual machine.
| writebetterc wrote:
| No, it's not? Using a VM is one way of preventing buffer
| overflows, it's not orthogonal.
| eru wrote:
| 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.
| bhaak wrote:
| 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.
| matsemann wrote:
| 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.
| forgotpwd16 wrote:
| >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.
| morshu9001 wrote:
| 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.
| lenkite wrote:
| > 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 ?
| jakozaur wrote:
| Not sure if I get this: WASM lets you use any language in the
| browser, though it still works way better with languages without
| GC, such as Rust or a transpiling C engine. Java is unlikely to
| be the best choice.
|
| In the era of LLM assistants like Claude Code, any engineer can
| write frontend code using popular stacks like React and
| TypeScript. This use case is when those tools shine.
| another_twist wrote:
| Java running in the browser is unlikely as typescript has
| largely tamed the mess of Javascript. Java requires a JVM and
| shipping an entire JVM so its runs atop another VM is kinda
| redundant. Except if JVM itself gets compiled and cached as a
| WASM bundle and Java compilers start accept WASM-JVM as a
| target. That will just be distraction tbh, Java has its
| strength in large scale systems and it should just focus on
| those rather than get caught up in Frontend's messy world.
| jeroenhd wrote:
| The article literally links to a frontend that does just
| that, run the JVM on top of WASM. It performs fine:
| https://teavm.org/gallery.html
|
| I'm not sure if I'd use it for a website or anything, but if
| my goal was to embed a simulation or complex widget, I
| wouldn't ignore it as an option.
| bloppe wrote:
| It doesn't run the JVM. It's an ahead-of-time compiler that
| converts Java bytecode to wasm.
| jeroenhd wrote:
| 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).
| eru wrote:
| > 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.
| another_twist wrote:
| 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.
| zkmon wrote:
| 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.
| grizzles wrote:
| Compose multiplatform is the spiritual successor to JVM in the
| browser. Compiles to wasm, modern api, great developer
| experience. It's kotlin so not java, but easy for java developers
| to learn.
| wiseowise wrote:
| > great developer experience
|
| Compared to Java, maybe.
|
| It is a far cry from modern frontend development with vite.
| ahmeni wrote:
| 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.
| ptx wrote:
| > _post your applet on a web page, and anyone on the planet could
| run it instantly_
|
| "Instant" is a strange choice of words to describe JVM startup
| performance. I recall the UX of encountering an applet involving
| watching a Java splash screen while the browser is frozen.
| jeroenhd wrote:
| 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.
| skerit wrote:
| I've been using TeaVM for a while now, and it's pretty great.
| kaluga wrote:
| 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.
| elric wrote:
| > 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.
| kaluga wrote:
| I get the skepticism -- browsers are massive, and the
| security surface has absolutely grown. But I'd still argue
| "properly" in the sense that we now have standardized,
| vendor-neutral APIs, permission prompts, sandboxing, CSP, and
| the ability to hard-disable features.
|
| Applets gave you opaque binaries with full system access by
| default; the web at least gives you mechanisms to audit,
| limit, and turn off capabilities.
|
| And yes, a lot of the modern API surface exists because ad-
| tech pushed the envelope -- no disagreement there. But the
| same standardization that helped them also enabled PWAs,
| WASM, privacy-preserving modes, and tools like TeaVM.
|
| So maybe not "properly" as in "perfect," but "properly" as in
| "the ecosystem finally has levers for users and developers
| that plugins never offered."
| panny wrote:
| >shrink the generated code and obfuscate the intent, to
| complicate reverse-engineering
|
| Says that like it's a good thing.
| geokon wrote:
| Wouldn't it make more sense to run/emulate JVM bytecode on WASM
| instead of compiling Java to WASM? It seems like that'd be a much
| easier task.
|
| From a high level WASM and JVM byte code seems incredibly similar
| (though I'm sure the containerizing and IO are radically
| different). I never really understood why WASM wasn't some JVM
| subset/extension.
|
| Not an expert at all in this, so genuinely curious to hear from
| someone who understands this space well
| DarkNova6 wrote:
| 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.
| rimmontrieu wrote:
| +1 TeaVM is crazily good. Comparing to GWT it has faster build
| time and better exports to javascript. I've built so many games
| using libGDX + TeaVM and quite happy with the workflow and
| results.
|
| Here's one of many: https://ookigame.com/game/flappy-bug/
| iamcreasy wrote:
| Do you have to rewrite GLSL shaders when migrating a game from
| desktop to browser?
| skybrian wrote:
| 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
___________________________________________________________________
(page generated 2025-12-08 23:02 UTC)