Java: Winning Many Battles, Now To Win The War

Java is winning many battles these days with 6 month release cycles, exciting new features, and more. However, there is a bigger war looming: the war for the browser. This is a war Java can't afford to lose. Read on for a winning strategy and what you can do to help.

A Bit Of History

In the late 90's and 2000's, Java had a strong presence in the browser. Java Applets were Java UIs that ran directly on a web page — think Canvas but with Java APIs for drawing and sound. Java Web Start let you launch full Java UIs from the browser. Both of these could communicate with services running on Java App Servers, for a full-stack Java experience. Indeed, the initial excitement over client-side Java led people to try it out server-side, where it became even more popular. Remember this for later: client-side dominance has a history of extending server-side.

Fast-Forward 20 Years...

Here in 2020, things have taken a turn for the worse. All major browsers have disabled support for Java (and indeed most non-JavaScript technologies). Web-based front-ends are usually coded in JavaScript or some wrapper designed to make it less problematic (like TypeScript).

Yes, you can still make websites using Java technology. There are plenty of 'official' technologies like JSP and JSF. Unfortunately, these technologies are entirely server-side. You can generate the page using Java libraries and business logic, but once it is sent to the browser it is static and lifeless. User interaction requires one of two ugly options:

A round-trip back to the server (slow — a bad user experience)
JavaScript embedded in the middle of your otherwise pristine Java-generated page

Some teams forgo Java altogether and build their front-ends entirely in JavaScript. Having made that decision, some go even further and look at options for running JavaScript server-side too. Sound familiar? This is how Java once took over the computing world.

Winning Many Battles

Java fortunately has not stood still. The Java Enhancement Process (JEP) has avoided bureaucratic quicksand and has produced numerous improvements to Java through the years, most of them well ahead of JavaScript.

Improvements are now coming every 6 months, thanks to the new release cadence. Already new garbage collectors, easier to use strings, and improved threading are available either for production or for evaluation. However, when you think about which of these innovations are for building browser-based apps, you quickly realize that Java client-side innovation has all but stopped, at least via the official channels.

As the famous saying goes, we don't want to win the battle but lose the war. How can Java increase its relevance? How can Java win back client-side developers? How can Java prevent other technologies from leveraging front-end dominance to win the back-end, like Java once did to other technologies?

How To Win The War

To win the war, Java needs a strong client-side option. One that lets developers make modern web applications using Java code. One that leverages web technologies. One that supports components. One that builds quickly. One that produces fast-downloading, high performance, 100-Lighthouse-scoring apps. One that plays nicely with other JVM languages. What does Java need?

What Java needs Is TeaVM

TeaVM is an ahead-of-time transpiler that compiles Java classes to JavaScript. It lets your Java code interact with Web APIs and the DOM. It also includes a rich framework for developing web applications called Flavour. Some of the many powerful features of TeaVM and Flavour:

Numerous Web APIs ready for use via type-safe Java wrappers.
A rich component framework to build apps from reusable components
Numerous pre-built components
Single-page app support with a shadow DOM and routing
Easy, transparent calls to web services

If you are a Java developer who is building a browser-based user interface, TeaVM is for you. There are two main styles of TeaVM apps:

Graphical apps that draw their entire UI on a Canvas and have very little HTML or CSS. These apps may just need TeaVM.
Single-page web apps that use HTML and CSS. These apps benefit from using the Flavour framework on top of TeaVM to handle routing, invoking REST services, and JSON parsing.

However, it doesn't have to be all or nothing, there are hybrid possibilities like the following:

A primarily Canvas-based app that uses Flavour to occasionally show other HTML pages.
A primarily HTML-based app that includes a Canvas on certain pages.

Whatever path you choose, you'll find that writing your client-side in the same language as your backend is a truly liberating experience. Share data structures throughout your app. Use your IDE to refactor interfaces and model classes in the client and server simultaneously. Use the same tooling (build tool, dependency management, static/dynamic analysis tools) for your entire product. Productivity and developer satisfaction are dramatically improved.

How To Move Forward

TeaVM is ready for use in your projects. It is stable, documented, and has example code on the TeaVM site, as well as elsewhere.

Most of all, TeaVM needs your endorsement and promotion. Instead of discussing and advocating legacy Java web technologies, help ensure Java has another 25 years of success — please promote and use TeaVM!

How to help?

Build your first TeaVM project. It takes just 2 commands.
Read the forums where developers discuss TeaVM and Flavour
Dive into the source. The TeaVM and Flavour code is well-organized and extremely useful. When creating your own JavaScript mappings and Flavour components, you have a large collection of examples to reference in the project codebase.

Thank you for reading this. Let's win this war together!