When HTML5 rose, the Java desktop era came to an end

Author | Steve Hannah

Translated | Nuclear Coke

Editor| Yanshan

The advent of Google Maps in 2004 marked the end of the Java desktop era and changed the basic definition of "cross-platform" in the desktop environment.

The author of this article reviews the development of the Java desktop from a personal perspective, based on what he saw and felt when he was a Java developer in the late 1990s, mainly to explain why the once "killer" desktop language Java has been in decline since the 21st century. It is worth mentioning that the author is now making a developer-friendly Java desktop deployment tool (jDeploy), but in fact, he still hopes that Java can regain its style and become attractive to desktop development again.

This article is the second in a series of articles in which the author reviewed how Java's dominance of the desktop vanished in just a few years from 1999 to 2005. The original Java can be described as a satisfied, with the Applet Mini Program technology shock four, determined to redefine the "desktop" in the Internet era. The future of the Internet lies in "cross-platform", and it is the blood of "cross-platform" that surges in the veins of Java, and the advantage is in hand! Unfortunately, in hindsight, this cross-platform does not seem to be the other. Next, let's continue to follow in the author's footsteps to see what happened to the Java desktop between 2004 and 2007.

The last days of the Desktop Dynasty

Around 2002, I was in the customer service center to provide customer computer and printer technical support. My friends and I were crammed into a small cubicle, facing a desktop program. Through this software, we can quickly query customer and product information, and record important information in the call.

In a typical customer service call, we ask the customer for the serial number of the product and then enter the result into the system. If they've called before, the system outputs a window with the product's full history and details of previous requests for help. After referring to the fact records left by other colleagues, I can also operate the tabs and function buttons in the interface, such as helping customers replace new machines.

I don't remember the name of the app, it may have been specially customized for the company or the customer service center. I was supposed to be a PeopleSoft (Renke Company, which was acquired by Oracle in 2005), but I wasn't quite sure. In summary, this desktop software runs on Windows 2000 systems and is certainly not a web application. It's actually quite complex, with a lot of menus and forms, but once you get started, the whole experience is pretty good — fast, responsive, and hardly any delays. For example, enter a phone number to query customer records, we only need to enter the number in the "Phone" field, and the rest of the blank form will be filled in with customer information immediately.

As far as I know, this program is certainly not written in Swing. But today, countless companies around the world use enterprise desktop software written by Swing, and they are very similar to the app I was exposed to. In other words, Swing has met all of our expectations and imaginations for desktop business software in 2001 and 2002.

After six months on the job, a new instruction came from above asking us to replace the previous desktop software with a web application. It was said that the new system would make our job easier, but just ten minutes after the first training session, we realized that this was all nonsense: the new system was a mess!

I don't quite remember whether IE 5.5 or IE 6 was used, but in short, the pre-AJAX web environment. Now after entering the serial number in the product field, a window will pop up with the words "Loading... Do not close this window". After a few seconds, the window disappears on its own and the customer details appear in the form. Anyway, whenever you need to get content from the server, this unfortunate window will pop up. The leader also reminded us not to click "refresh" in the browser, saying that this would destroy the state of the system. So whenever there was a problem, I had to log out and then log back in.

I don't quite understand why companies are replacing their previous desktop software with this "silly" web application. Probably for cost reasons, after all, web applications are cheaper to develop and maintain than desktop software. Or it's software vendors imposing pressure, such as "The Web is the future, and everyone must accept it!" "But, is there really such a strong Party B?"

In any case, an important message is revealed here: Web applications have begun to eat into the living space of desktop software before they have been developed and perfected. The only question is how long it will take for a web app to keep up with the desktop software experience. And as it turned out, it didn't take long.

Uncanny Valley Effect

Back to Java. Enthusiastic supporters are expanding the desktop landscape of the Java empire, and a passion for WORA (write once, run anywhere) leads them to the secret valley between cross-platform mini-programs and "native" applications. At that time, the Java IDE was mainly for three major build goals:

1. Mini Program

2. Java Web Development

3. Executable Jar file

Yes, there is no option to develop native applications directly. Although there are third-party tools that can convert Jar files into native applications, they are complex and extremely cumbersome. Only the most "cruel" to themselves can insist on using it. Java's courage to ignore this is a judgment of the future — native desktop applications are finally obsolete. In fact, this prophecy is correct, but it is biased in time.

Looking back at 2022, there are a lot of obvious problems with Java. Applications can be deployed as web or natively, but neither form has a hint of "native" feel. Web Deployed applets run in their own "sandboxes" and are integrated into web pages, and the entire process is slow and sluggish.

The rise of HTML5

While Java always wants to build a bridge between the Web and the desktop, it is inherently wrapped up in the Web. By 2002, many enterprises were migrating their original desktop software capabilities to the web. The cost of building, maintaining, and deploying these web applications is indeed much lower than desktop software, at the cost of compromise on the user experience.

It was also around this time that Java began to promote the concept of "rich Internet applications", hoping to distinguish good Web applications from poor Web applications. But by the time Google Maps was officially unveiled in 2004, Java's little trick was completely bankrupt. Google Maps set the benchmark for rich web applications with shocking results, and people use HTML5.

I recently watched bill Atkinson's old video showing Apple enthusiasts MacPaint for the first time. The first time he drew a pattern with the brush tool through the mouse, the scene was full of "wow" and applause. This is called groundbreaking. The first time I saw Google Maps was a similar feeling, the map can be seamlessly zoomed and panned, and there is no trace of stitching at all. The new technology used here is called AJAX (Asynchronous JavaScript and XML), and for the first time, people have been able to seamlessly make requests to the server backend in a web application. Now of course all of this is taken for granted, but in 2004, developers had to rack their brains to hide the frames or pop-ups that made people want to vomit, ensuring that new data could be loaded from the server without refreshing the entire page.

As a web developer, I certainly yearn for the endless possibilities. But from a desktop development perspective, this historic change doesn't seem to have had any impact on the desktop, especially Java.

Before HTML5, "cross-platform" meant "across Windows, Mac, and Linux," so the scope of the cross was still within the scope of the desktop. I didn't realize it at the time, but now that HTML5 is here, it represents the dawn of a new platform era— it will become an objective standard for client applications; more importantly, Java doesn't support the platform. Suddenly, the WORA philosophy went blank — swing apps worked on every platform, except for the most important one: the web browser.

Java developers are "fleeing"

So where did the Java desktop developers go? There are three main directions:

1. Server

2. Browser (HTML5)

3. Desktop app

If everyone's basic positioning of themselves is first of all "Java developer" and then "client developer", then they should eventually choose java at the moment still occupies the active platform - the server. If you're more interested in user-facing development (client-side) and focus on Java's cross-platform value proposition, your next goal is likely to be HTML5 (Javascript/HTML/CSS) development. If you're a hardcore "royalist" (like me), stick to Java desktop development while watching your circle get smaller and smaller.

GWT: Bring Java into the browser

In the early 2000s, JavaScript development tools were still in their infancy. Most web developers can only use a text editor to write .js files. Simple validation scripts and interaction design are fine, but this rough approach certainly doesn't scale and support large enterprise application projects. In addition, the JavaScript language of the time did not have the functionality that developers needed for important operations such as refactoring, such as static typing.

In contrast, Java already has a comprehensive set of development tools that can be easily scaled to projects of any size. By 2004, the leading and mature Java IDE had become the benchmark in the development environment, with static types that greatly simplified maintenance for large projects. At this point, the only regret is that the Java application cannot run in a web browser (only applets can).

To solve this problem, Google created GWT (Google Web Toolkit). This is a Java-to-JavaScript compiler and runtime library that allows developers to write applications using Java's set of leading development tools and then deploy the results as JavaScript applications to run natively in the browser. This runtime library contains implementations of many core Java APIs such as java.lang, java.util, etc., ensuring that business logic can be shared smoothly between GWT applications and server applications.

In terms of user interface, GWT also provides its own functional components, the essence of which is to bind each part in the form of Java to the native HTML part in the browser. While we still can't use Swing code directly, and most third-party libraries are not supported, we can at least use the Java development environment and core APIs that we are most familiar with.

So that doesn't really get Java into the browser — the standard JavaSE library is still largely unsupported, and core features like threading don't work. But at least for most use cases, that's enough.

Google has used GWT to develop many popular HTML5 applications, the most famous of which is Gmail, and this project has spawned a small but fairly active open source community. While the impact is no longer what it used to be, this community still exists today. At the same time, incremental improvements in JavaScript tools are crowding out GWT's living space, and a series of more modern solutions over the past decade have allowed us to use Java more "brainlessly" in browsers.

Gold rush on servers

The advent of HTML5 has upended Java's ambitions to dominate the desktop, but there's good news here. Without having to be distracted from the desktop, Java has evolved on the server side. Java is ready for battle and strives to meet the new needs of developers for back-end services — after all, without a backend, even the best web applications can't come out.

Java's popularity on the server side continued to grow over the next few years and attracted a lot of attention from the entire ecosystem. Third-party libraries are constantly emerging, and the birth of Maven in 2005 made the use of third-party libraries less complicated and cumbersome. No additional downloads, no dependencies, just paste the fragments into the pom file and it will automatically download all the corresponding dependencies.

Java's development tools are also constantly improving, thanks in large part to Java's predominance on the server side. These improvements also had a positive impact on desktop developers, allowing us to use the same IDEs, compilers, virtual machines, and libraries as the server. However, the desktop developers who represent the "last insistence" of the Java world have not been able to open their eyes, and are still circling around the improvement and deployment of UI libraries.

When I have a problem, my habit is to go to Google and search to see if anyone else has encountered or solved the same problem. But on Swing development, I found that the latest search results were basically around 2005, and there was basically no new additions since then. When I can't find an answer, I occasionally write a question analysis blog post. And when I had a similar problem two years later, what I found on Google was my blog post from two years ago... Seriously, are there still gasping Swing developers right now? It feels really bad.

Redefining desktop apps

By all accounts, the rise of the Web has made the concept of "desktop apps" clear. Java's original cross-platform client development vision did not distinguish thin clients (primarily interacting with remote servers) from native full desktop applications. This not only makes it more difficult to understand, but also makes the design of the security model a bit confusing. The "platform" in Java's understanding is the computer itself, so awkward sandboxes are used to restrict API access that can pose a security threat, such as accessing the file system. This is the root cause of all security vulnerabilities in Java and the reason why Java was expelled from the browser world.

This "sandbox" based development experience is pretty bad because it's easy for us to accidentally "cross the line" and trigger a security exception. The end result is that almost all clients request "trusted" access to the system, bypassing the sandbox restrictions altogether.

HTML5, by contrast, sets a clear boundary between the web and the desktop. Web applications do not have access to client computers by default, and browsers are the "platform," which makes it easier and easier to secure client applications.

As a result of this change, the category of "desktop" has become smaller, and many software that was previously considered "desktop applications" are now classified as "client applications". Specifically, if an application is only responsible for providing UI when the user interacts with the server, it belongs to the client application. The concept of "desktop" now refers to applications that integrate with native devices in some way, including access to file systems (development tools, file conversion tools, etc.), calls to certain platform-native APIs that are not present in the browser, and software that performs hashrate-intensive tasks.

This is not to say that there is no intersection between "client" applications and "desktop" applications — of course, both involve GUIIs, and many modern desktop applications also need to access servers. So both desktop and client applications can enjoy GUI toolkit improvements, improvements in the technical aspects of media (audio/video), and networking.

A new journey for the Java desktop

In 2004, I developed some commercial-grade Java desktop applications on both Mac and Windows. HTML5 has little direct impact on such applications. Combined with my own needs, Swing is still completely sufficient, and the various desktop deployment tools I use to build native bundles work correctly.

Unfortunately, the tech industry is a world of no-advances. Over the next few years, the web platform grew by leaps and bounds, while Swing stagnated. By 2007, Swing was dying without change. It needs to respond to the historical trend of HTML5, and the ultimate answer is JavaFX. It's a novel Java UI toolkit that brings Java to a modern new world of GPU acceleration, scene graphs, 3D graphics, and web views, with support for modern audio and video codecs like MP3 and MP4.

In the next article, we'll review the popularity and far-reaching impact of JavaFX, as well as other trends in the Java space before the Mac App Store emerged in 2011. Don't underestimate the Mac App Store, its appearance is a "decapitation operation" of the Java for Mac desktop development ecosystem.

(Interested friends can leave more messages, InfoQ will continue to translate the series of articles according to everyone's needs for readers)

https://jdeploy.substack.com/p/the-decline-and-fall-of-java-on-the-970