Hacker News Reader

Comment by jasode | Hacker News Reader

Excerpt of email reply from Nathan Myhrvold is mostly correct:

>The new Java applications are NOT credible threats to traditional PC software any time soon. [...] Cool new technology always expands rapidly into NEW ares (where there is a vacuum).

Java's hype of Write-Once-Run-Anywhere to kill Microsoft Windows didn't happen on client desktop apps like many expected. Desktop apps are still C++ and some newer apps are Javascript(Electron). Yes, there are a few niche desktop apps using Java like JetBrains IDEs but history has shown that Java made more market penetration on server-side code. The 1990s dot coms like Ebay and Amazon were early users of Java on their servers. I read that Google uses Java on the web servers to generate the results page. (To be clear, I think Google uses C++ for the crawlers to build the index and the algorithms for search engine ranking.)

View on HN

Java didn't kill the desktop. The web - Javascript - has put a huge dent in it, especially via the medium of smartphones which were never going to run Windows desktop software. (+). The desktop limps on but it's not quite as dominant as it once was. You can run an entirely successful multibillion dollar software business without a single Windows machine being involved at either the client or the server or developer ends.

(+ don't mention Continuum or UWP or Windows Phone)

You mean the native app stores on smartphones? Because that's what competes with desktop software now that people user their phones for computing. But you can still get the app version of windows desktop software.

Store apps, or just web apps in general.

> you can still get the app version of windows desktop software.

Not really - you get app versions of portable software, which may be entirely rewritten from a similarly-named desktop app, but they're not the desktop app. It is as you say a separate version that requires separate maintenance.

What you can't do is take a 1996-era Windows app and run it on a smartphone without a complete rewrite. Surprisingly, you could do this with Windows CE for handhelds, like the Compaq Pocket PC which ran ordinary MFC apps with minor tweaks and a recompile.

Microsoft had one last go at desktop/phone unification with UWP, and that lost in the market.

>Java didn't kill the desktop. The web - Javascript - has put a huge dent in it

Nah, I disagree. Mobile killed the desktop, 85% of that is Android, and most Android apps are written in Java. So yeah, Java did eventually "kill" the desktop. But I would point out it was mostly low cost, battery powered, untethered mobile, not the Java language or runtime. What Java solved was a chicken/egg problem where there are no developers because there's no market because there's no developers...

The web never killed the desktop. There are no high end games on the web. There are no native features on the web. The web provided forms and ssl; an e-commerce platform. That's it. Everything outside of e-commerce on the web is ad supported which leads back to e-commerce. All roads lead to Rome. That sums up the total contribution of the web on humanity as a whole IMO. Yes, you can list off small exceptions, but most people using the web are participating in e-commerce at some level.

Web provided YouTube, Facebook and Netflix way before mobile became dominant.

IMHO this was because the JVM at the time had bad performance compared to native apps. I certainly avoided Java apps on my machine as much as possible if there was a native alternative, the extra load on consumer machine resources at the time just wasn't worth it.

When did JVM switch to the insanely fast HotSpot JIT?

Later, but HotSpot to this day means “less slow” - it’s a lot better than it used to be but you still need considerably more RAM and CPU than native apps.

I don't think the need is that larger when compared to today's applications, esp. Electron based applications.

Eclipse still uses less resources than VSCode/Atom while juggling more balls at the same time.

Just because someone managed to come up with a worse alternative doesn't make Java good. The main problems, initial JIT time and fixed heap size still remain.

Java has always been tunable to be more aggressive at returning memory to the OS if you are worried about the resident memory size. Newer versions of Java with the more advanced GCs are even better at it.

Ultimately Java's runtime performance wasn't really to blame for it's lack of success but rather the awkwardness of JRE distribution, garbage applet sidetrack and lack of high quality GUI toolkits that actually felt native rather than attempting to do "platform independent look and feel".

How does the tuning work? To me it still seems that JVM (or at least the version bundled with JetBrains IDEs) keeps allocating memory until it's near max heap size and it's up to the user to find the value that's large enough stop the app getting stuck doing full GC but leaves memory for other apps.

JVM can be tuned via the command line during startup. Eclipse comes with 512MB as the heap size, and you can enable a small gauge to see how it's doing. I've never seen "This heap is small, please give me more space" error from Eclipse. Also, latest versions of Java (starting with 16 IIRC) doesn't grind to halt during large GC passes.

I've developed enough applications in Eclipse during past 20 years, and it has become from being an absolute lead ball to something agile for its size, both in macOS and Linux. I've found an infinite loop bug in CDT, and only with that I was able to make JVM throw the towel, and call it quits.

JVM is very smart and resilient in memory management, I've seen some stuff during my life.

Defaults are important. The world runs on defaults. Bad defaults cause real problems and take real work to fix, so it's fair to blame software for poor out-of-the-box behavior, even if it can be configured away.

Well, a message saying "This heap is small, please give me more space" would be all too helpful. I haven't touched Eclipse in years, but Clion and Rider have this failure mode where they just use all the CPU all the time and it's up to user to figure out that it's GC and how to increase the heap size. I was hoping for an option that would mean "use all the memory you need but don't keep the maximum allocated just in case". The current -Xmx seems to be more like "postpone full GC until the maximum has been reached".

I'm not sure if it's significant that Jetbrains IDEs and Eclipse are separate products. Google can't distinguish between different Jetbrains products in search results, maybe Eclipse can be lumped into same group by some logic.

Jetbrains IDEs have this "heap is too small" message though.

I have never had the patience to wait for it.

Atom, yes, VSCode, no. The latter is noticeably faster and uses less RAM — and the JetBrains suite is even worse.

A large part of this is cultural. The Java world has been prone to high complexity styles which are hard to optimize and there doesn’t appear to be much social expectation that you profile or improve code until you max out what you can easily fit on a single system.

Jetbrains’ IDEs do more things by an order of magnitude than a vscode full-of-plugins, so it is not a fair comparison.

Far less than an order of magnitude — and it shouldn’t be the case that every advanced feature slows down core functionality like how long it takes for a key press to render when you’re not even using that feature. They have lots of functionality but proponents have always noted the … stately … speed and these days the ones I know have moved to VSC because it’s competitive for the features they use and they benefit from better performance all of the time.

You still can’t really conclude that it is due to Java somehow.

Also, if jetbrains would finally use a non-deprecated GC and a slightly more GC-friendly max heap setting, intellij would have much better latency. (You can try this out yourselves, just go with G1GC and increase heap size for a good improvement. But the best experience would come from ZGC but it is only available in a newer runtime than the bundled 11)

Definitely, but when almost every Java program I use has issues with performance and memory it suggests that the culture doesn’t value those things highly enough. The same is often true in the JavaScript world, which makes VSC interesting because it’s famously an outlier in the Electron world.

> Definitely, but when almost every Java program I use has issues with performance and memory it suggests that the culture doesn’t value those things

I think it is still a bit of a baseless case. What about java’s gRPC library? Elasticsearch? Or a bunch of other high-performance Java programs?

Solr is the one exception I have personal experience with. The rest of it basically comes down to the culture of complexity: HotSpot is no match for the average enterprise architect.

> The same is often true in the JavaScript world, which makes VSC interesting because it’s famously an outlier in the Electron world.

That's because it's not a JS problem so much as it is a problem with the culture of NodeJS/NPM. It happens to be that NodeJS has pretty much cannibalized JS development, however.

Two large pieces of software that make heavy use of JS that most people don't even realize—because they don't feel like the kinds of apps that NPM programmers produce—are Firefox and the Gnome desktop. They're by no means examples of the top end of world's snappiest software, but they are solidly middle-of-the-road in a way that most Electron apps, for example, are not.

Dominant platforms that capture lots of developer attention (like NPM today, and Java starting 15–20 years ago) end up capturing the attention of the sort of programmers who are going to be causing trouble no matter what ecosystem they're working in.

I mean, both programs hardly use JS for anything other than scripting the behavior of a very optimized C/C++ codebase. So I don’t think it is fair to call them JS apps — I have never heard Firefox referred to as such.

Your remarks here, esp. re "hardly use JS", make for a wildly misinformed comment. (You realize that every Electron app also has at the core a "very optimized[...] C++ codebase"? Aside from that, Gecko makes very little use of C and by now makes extensive use of Rust.) XUL-based apps were doing the Electron application architecture before Electron (or NPM, for that matter) even existed—and on average they've done it better.

> I have never heard Firefox referred to as such.

... so?

The fact that you aren't aware how heavily reliant that Firefox (and Thunderbird, and Zotero[1]) is on JS for its UI and other application logic doesn't exactly change anything. In fact, that most people aren't aware of it is rather the point of the comment that you're responding to...

1. https://news.ycombinator.com/item?id=29774097

While Firefox's JS usage is more ingrained and near to its core, GNOME's and KDE's JS usage is nowhere as deep. They both use JS (and QML in KDE's case) as strict scripting engines, which directly bind to C++ codebase underneath.

GNOME's JS introspection libraries are even "autogenerated" from the source and header files.

I played with both, and the weight the JS parts are lifting are pretty minimal. All the stuff is done by the C++ parts underneath.

It's like using TensorFlow, SciPy or a similar C backed library and telling that you use Python for computation. Same thing.

At the end of the day, any Electron app I use (I use TiddlyDesktop for example) is using more RAM and CPU, and bogging down both considerably more w.r.t. Firefox, KDE or Eclipse. When a simple application which has a very optimized C++ core is using more resources to show a simple web page and manipulate it is using comparable resources to my IDE or primary browser, there's something very wrong.

I've done more than play with Firefox and Mozilla toolkit code. "All the stuff is done by the C++ parts underneath" is an overstatement. (Not least of all because a bunch of stuff is now done by Rust parts and not C++ parts.) Plenty of the behind the scenes stuff is JS.

> At the end of the day, any Electron app I use (I use TiddlyDesktop for example) is using more RAM and CPU, and bogging down both considerably more w.r.t. Firefox, KDE or Eclipse. When a simple application which has a very optimized C++ core is using more resources to show a simple web page and manipulate it is using comparable resources to my IDE or primary browser, there's something very wrong.

These remarks doesn't really make any sense here. I didn't show up to the party defending Electron apps and their authors. My comment was an explicit indictment of typical NPM and Electron development practices.

> I've done more than play with Firefox and Mozilla toolkit code. "All the stuff is done by the C++ parts underneath" is an overstatement.

By both, I meant KDE & GNOME. I didn't dive into Mozilla/Firefox stuff, but as far as I understand, since setting enterprise stuff and locking features, etc. (I forgot the name of the enterprise stuff, it's long time ago) is done in JS, JS is more than skin deep in Mozilla/Firefox codebases.

This is understandable though. Firefox is just Netscape, and they just invented JS. Not much involved otherwise.

> These remarks doesn't really make any sense here.

They're not direct counter-arguments to you. Just I've wanted to say that, even though the Electron is built on a C++ core, it's extremely inefficient and wastes a lot resources for what it does, that's it.

Still, it’s like claiming that OpenJDK is written in java — yeah, the SDK has many parts in Java, but it is still a C++ executable that has bootstrapped another language.

Is the CSS layouting engine, the network stack, the goddamn JS interpreter or the myriad other literal millions of lines of code of firefox is in JS?

Of course electron apps bundle a.. browser, but you are just pedantic. An electron app’s core functionality is not the bundled browser.

> Of course electron apps bundle a.. browser

They don't. You are conflating Web browsers and the engines that power them. Web browsers are applications unto themselves. They require lots of application code separate from the underlying engine. You don't get a Web browser by compiling a browser engine and calling it a day.

> Is the CSS layouting engine, the network stack, the goddamn JS interpreter or the myriad other literal millions of lines of code of firefox is in JS?

VS Code, an Electron app written in TypeScript, requires all the same components. And you keep saying "Firefox" when it's not appropriate to do so.

The millions of lines of code in _Gecko_, along with Spidermonkey, establishes a platform for building apps that's on par with the Electron platform. Gecko + Spidermonkey does not a Firefox make, however. The code that makes Firefox Firefox[1] is in a separate application bundle, which includes on the order of hundreds of thousands of lines of JS.

1. ... and not, say, Zotero, which is literally built by downloading a release build of Firefox, stripping out all the Firefox code while leaving Gecko et al intact, and dropping the Zotero code in its place.

Latest Eclipse (esp. after they switched to 4 releases/year schedule) is very lightweight and nimble for what it does.

It's being optimized for being faster and lighter every release, and it really shows. I mostly develop C++ and Python in Eclipse, and CDT's indexer is really good, and it's not using gigabytes of RAM, or doesn't require LSPs to be productive. OTOH, Eclipse supports new things like LSPs, direct builds to containers, etc.

So, it's getting faster, doesn't getting heavier resource wise, and keeping its edge tech-wise. I'm a happy camper.

Oh, and the plugins doesn't need official binaries, if you're inclined to build your own.

Personally I find Jetbrains IDE, Phpstorm specifically, very snappy. Much better than VSCode in performance.

I few years ago I managed to run Phpstorm on a ASUS Eeebook with an Intel Atom 32 bit 1.3 GHz CPU & 2GB RAM. Not optimal but doable.

I’m impressed what Jetbrains has managed to squeeze out of Java. However I’m not aware of any other Java desktop app that that works as well.

Only thing you can’t do is to manually run every inspection there is on the entire project, takes forever and will eat your CPU even on a fast machine.

JetBrains IMO is about the same performance as VSCode for waaaaay more ease and functionality.

It doesn't give me that deliciously snappy feel compared to something like terminal NeoVim, but my productivity is ultimately much higher on a JetBrains IDE

This is only partly true. HotSpot is pretty amazing performance wise. For certain code patterns it really does produce assembly competitive and even better than what you get from the equivalent vanilla C++ solution.

The issues are (a) it only kicks in once something gets profiled quite a few times (so your first encounters with a function - the one you base your impressions of usually, are at its worst), (b) the overhead of JIT weighs down the machine further at exactly the moment (a) is occurring. And then (c) there are quite a lot of code patterns and in particular architectural styles encouraged by the Java ecosystem that are hostile to this whole process.

I do wonder why Java has not gone the python direction of caching the JIT output in binary form so at least the 2nd time you launch an app it doesn't need to be redone every time.

It did actually work for a time that you could point the jvm to precompiled class files, but it got discontinued (it was part of GraalVM which has a different pace to OpenJDK)

But imo that is only relevant for startup - otherwise the problem with Java’s JIT compilation is the identity of objects, which makes it much harder to do some optimizations. Hopefully with valhalla we will see quite a boost.

It's complicated to do binary caching for various low level reasons. Amongst other things, the generated binary code is specific to the precise location in memory and makes lots of assumptions about the state of the runtime like what classes have been been initialized.

Still, HotSpot has been slowly (too slowly) getting AOT-like optimizations in the form of AppCDS. It doesn't actually store compiled code but a lot of other internal data structures can be stored to disk in native form and just mmapped at startup. It's usually a 30% win or so, which isn't bad.

HotSpot took 2 decades to get to its current performance, and while its JITted performance is good, for desktop apps cold boot performance is at least as important.

Moore's law didn't hurt either.

I think there's a big confounding factor, though: people self-select into platforms depending on what they care about. People who self-selected into Java didn't value perf. They were then inclined to ignore their own performance problems for the same reason they selected Java: they didn't value perf. That's why so many Java GUIs chug so hard, even today, when it really can't be blamed on Java itself.

For instance, Ghidra: if you leave a filter active in a GUI box and run an analysis tool, sometimes the runtime of the tool explodes from minutes to days because it refreshes the GUI after each of the zillion model tweaks the analysis tool needs to perform. It's not Java's fault that nobody put in the code to throttle GUI updates, but the same list of priorities that led the creators to choose Java also led them to ignore a massive perf landmine sitting in the middle of the road for all to see and occasionally hit.

I recently fired up LibreOffice Sheets to see how it compared to Google Sheets. It took four entire seconds to switch to editing mode in a cell. Every time, not just the first. If I were to root cause the issue, I'm sure it wouldn't be Java's fault -- but I bet that the same priorities that led the project to choose Java led them to ignore a four second stall in their most critical user interaction path.

Both of these projects are free, so I'm not upset about getting what I paid for, but I have plenty examples from corporate Java GUIs as well. I don't think this is a Java problem, I think it's a priorities-held-by-Java-programmers problem.

Reminds me of this post: https://nibblestew.blogspot.com/2020/03/its-not-what-program...

In the case of java though in my opinion the problems start at the std library that sometimes forces you to write really inefficient code, or reimplement everything yourself.

> I recently fired up LibreOffice Sheets to see how it compared to Google Sheets. It took four entire seconds to switch to editing mode in a cell. Every time, not just the first. If I were to root cause the issue, I'm sure it wouldn't be Java's fault -- but I bet that the same priorities that led the project to choose Java led them to ignore a four second stall in their most critical user interaction path

That's a slightly confusing comment because while it does integrate it in some components, very little of LibreOffice is written in Java. From what I understand, the core of it is all written in C++ and it's often held up as a canonical example of what happens when a giant C++ codebase gets out of control and doesn't manage complexity well.

Well, the stack overflows through the years seem to resolve similar issues by pinning the JRE version, so I assumed it had something to do with it. Sounds like that might have been a bad assumption. Either way, I never tracked it down. Plenty of options for spreadsheets these days.

The JVM can be as fast as you want, Swing would make your app drag along

I think you're ignoring the giant world of custom, bespoke, enterprise software which is majorly written in Java (and these days on web) - the fact which makes Windows in the Enterprise (Microsofts main money maker) much much less sticky as they would have liked.

The little bubble you're talking about is far from Microfts main concern.

Luckly, Linux and macOS never really could grow out of their niches to really hurt Microsoft.

> Luckly, Linux and macOS never really could grow out of their niches to really hurt Microsoft.

"Kind of" (indirectly as others pointed out) - the Dotcom bubble from a systems perspective was based on "Put these words on your VC funding paperwork and we'll throw money at you: Netscape Enterprise Webserver, ATG Dynamo (or similar), Solaris 5/6/7 on Sun E250s and E450s, Oracle Database and Java". I was at a services company doing systems work for Java engineers and built countless versions of this stack; java code was written on Windows workstations and deployed to the Sun servers (this might help explain why Java is deployed the way it is - many devs just zipped up a directory, uploaded it and unzipped it remotely).

Then Blackdown JDK[1] entered the room and changed the game - it gained it's first release right after the Dotcom bust and turned that stack on it's ear; now you could use Apache, Tomcat and MySQL (because Java developers could run MySQL on Windows, it "won the war" against Postgres at that time) creating a way to survive in the money-vacuum years following the Dotcom bubble crash when things were very scrappy and people were looking to just survive the storm if they could. My services company had to lay off some 80% of employees because all the clients dried up during the bubble burst.

There was a shot right here to have Java production workloads run on Windows Server (NT etc.) since all the java devs were doing it personally, but running on Linux was a much higher performing stack at the time and of course pennies compared to the previous stack even in the kernel's younger years or paying for Windows licenses (and more hardware). Red Hat's IPO in 1999 preceded the Dotcom bubble, putting them in the right place to handle these workloads post-Dotcom as they had a mature Linux offering with a business plan to Enterprise minded shops (appeal to the business folks - save money, have someone to blame if it breaks). Techs loved it because we'd been doing Linux for a decade and here it was about to take over the server world, and Java workloads were helping make that happen.

[1] https://en.wikipedia.org/wiki/Blackdown_Java

my understanding was that java was originally envisioned as a runtime for iot. i remember reading a lot about how they were expecting it to land in cell phones, set top boxes and other internet connected devices.

they started with applets in the browser. at the time javascript was incredibly immature and used mostly for client side validation of form fields; but was hated by users and developers alike because browser support was inconsistent leading to spaghetti code and bad ux.

java applets were also frowned upon. the jvm was quite heavyweight and would struggle to start up on the pcs of the time. the immaturity of the technology made the uis sluggish and fragile.

i don't think anyone expected it at first, but using java in web backends became very popular. i suspect this was because performance was reasonable once a server was warmed up and it was sort of turning into an ecosystem that a lot of money was being poured into. the microsoft ecosystem for internet stuff at the time was buggy and terrible, with its "systems built to run internally on corporate networks" lineage showing. on the backend, iis was known to be insecure and hard to code for and on the front end, nobody wanted to aid microsoft lock-in with client side vbscribt and activex.

the geeks wanted internet native unix based servers and the well trod options there were java, perl and php (or bespoke options built on them). nobody wanted to do strings in c/c++, further pushing towards high level languages of which java could be a performant one for heavy workloads.

ironically, the java iot dream was eventually realized by google with android. even more ironically, it's probably the most complicating and complained about part of the platform.

I don't know the numbers but mid 2000's J2ME was a very popular mobile platform. Don't know why it fizzled out.

ahh yeah. forgot all about the wapiverse. afaik there was really only one application, and that was the wap browser which was really simple except for ssl support.

i think most people didn't even realize their phones had something browserlike back then and even if they did it was tough to use.

i never used it. google's sms gateway was more useful for my purposes.

Not a J2ME developer but I've heard time and time again that it had extremely poor cross platform compatibility and each different handset needed modifications to the source to get it to function.

This was back when there were a million competing incompatible handsets. Not a fun time!

It was basically sort of like the web but for mobile Java - a whole bunch of not entirely compatible and uniquely buggy implementations, to which adding features was a very slow committee driven process meaning every new feature got reimplemented in 4 different incompatible APIs first.

Additionally at the time the mobile makers were totally in hock to carriers, who usually insisted on having their own app stores with totally developer hostile processes. So to even run on a lot of phones was a huge PITA because you had to get every carrier to sign the "midlet" and they had no easy process for this.

So the issue was not so much Java the tech - Android proved that - but more the model around how it was managed. Android took the basic concept of J2ME, dropped the actual APIs and design-by-committee (triggering the lawsuit with Sun/Oracle in the process), created a robust open source implementation, gave it away for free and invested heavily in their app store tech. And that led to success.

From Gates's email:

> I am literally losing sleep over this issue since together with a move to more server based applications it seems like it could make it easy for people to do competitive operating systems.

Gates was talking about server applications, and he was right. Within 10 years, people were using Gmail instead of Outlook and Google Docs instead of Word. Both are written in Java on servers not running Windows, exactly as Gates feared.

I mean it's also a lot of client-side JavaScript, but yeah, I thought this line was the most prescient.

As I've moved back and forth between Windows and Linux over the past 15 years, I've found it increasingly easy to do everything on Linux, and that's mostly because more and more of what I do is just in the browser. At this point, it's Linux on my personal laptop with a Windows virtual machine for only two or three Windows-only desktop applications that I still occasionally require.

As long as Firefox and Chrome are cross-platform, the OS matters less and less.

As an end user, you could definitely tell Java apps looked janky as hell.

> Desktop apps are still C++ and some newer apps are Javascript(Electron)

I think the reason java failed on desktop and electron works is because electron is an entire runtime packaged into the app. The java team failed to recognize that people want to install an app without worrying about external dependencies. Later on the Adobe AIR team failed to realize this as well and while AIR had a promising start it flopped as well due to external dependencies.

That’s a jar

web start enabled a user to double click to install (well cache) and run a Java application

Modern Java does work this way with bundled runtimes. But it made the transition quite late, indeed.

I’ve always wondered why Java didn’t take off more for desktop apps. Was it a compromised user experience vs native apps? Was Swing bad to work with? Did Web 2.0 come in and steal the show right when it was starting to gain traction?

Well, do you consider Electron a compromised user experience?

Swing is/was the same, and computers had way less power to make up for it in the early 2000s.

I don’t personally, but what matters here is that Electron has taken off and Java-for-desktop didn't seem to really. Maybe it was the tech, maybe it was user expectations at the time, but something was different. I’m just curious what that was.

It was a PITA to manage for end users. They had to install the JVM and update it when the JVM updater told them so. Many people didn't update (slow connections for a file size comparable to today's one, no time, etc.)

Then the application had its own non native widgets and was noticeably slower than native ones.

Then (more importantly IMHO) developers discovered that HTML interfaces were good enough even 25 years ago and being able to update a web application (they were no app back then) even only once per month was so much better than having to distribute thousands or millions of copies of a desktop application. Game over. BTW that was web 1.0.

I think it's the core, the 2D engine, just never got the love it needed to be a great place to start. Nobody seemed to prioritize making that happen.

Like, the antialiasing was noticably fuzzy. I never found an applet that looked like it belonged on the webpage. And when I built a few, it was a lot of work to even get font rendering to not be horrendous. And even then, you'd see what the browser rendered vs what the applet rendered and they were always off. I remember using images instead of font rendering sometimes.

So, if you made a swing app, it was easy to put together, but hard to make look "professional".

By the time of the Oracle acquisition, I'm pretty sure everyone just realized the browser and mobile "won" and that's why we just had JavaFX get broken off the platform and basically put out to pasture. But it's not like much went into the core platform itself to make building great UIs easy. The underlying 2D rendering just a great place to start.

I mean, even today, there's some serious performance issues with IntelliJ on 4k monitors with scaling. https://youtrack.jetbrains.com/issue/JBR-526

When I look at where JetBrains is going, it sure seems like they are building on top of a better 2D engine, in this case, skia: https://github.com/JetBrains/skija.

I wrote a Java Webstart app for internal users way back when. It was harder to work with and not as end user friendly as what I could create in VB5. Of course all my internal client were on Windows so VB was an option.

Then the web came in and stole the show. Even a slower web app was so much faster to develop and push out to 10k internal clients (that was a lot then hah).

As an end user, the UX was always goofy. If the devs made a lot of effort, it could look like a bad impression of a native app, but never exactly right. As soon as you'd hit an error state or edge case, you'd see some weird ass Java-looking error.

Electron is different, because we all got used to web apps, and electron apps are just web apps.

I never got why a web application with custom layout view is ok but a swing one looks funny I get the browser controls look native but still as a whole they also look different from a desktop application

Because Microsoft killed it.

Through IE, Microsoft controlled what you could run in the browser and they refused to upgrade the embedded JVM. Java Applets started becoming popular but then they stagnated.

Microsoft control was broken when Google decided create Chrome. Chrome is what allowed javascript to flourish.

I think that is glossing over some important details. Sun sued Microsoft repeatedly, and eventually stopped licensing Java to Microsoft. "Upgrading the embedded JVM" was not a user-friendly mandate... think of how annoying "upgrade" or "new version available" notices are today... now consider the same over a 14.4k modem. And finally, most Java applets sucked. Very few were "popular". They looked weird, non-native, had unfamiliar icons and menus, and were often slow.

> Desktop apps are still C++ and some newer apps are Javascript(Electron).

Just a nit, but .NET is used for significantly windows desktop apps than C++. I otherwise agree very much with your comment.

QT (C++) is very popular for desktop apps, and they feel much faster than anything on NET or Java

It didn't happen because Microsoft was able to kill it.

See, for a few years MS had a tight control over the browsers and they refused to upgrade the JVM in IE when they lost their infamous lawsuit against Sun. So Java Applets never flourish.

Microsoft control was broken when Google decided create Chrome. Chrome is what allowed javascript to flourish.

Google has a TON of Java. Some of the largest, most widely used systems in the world are written mostly in Java.

Reply on news.ycombinator.com