For some reason, the vast majority of developers has accepted the browser as the operation system for their applications. While there are some good reasons for this, I never really bought into it. HTML5 has eliminated most of the pain point of web applications, but I still insist that most customers don't really want to use a web application. We've taught them to accept to open the browser to do their daily work, but there are still quite a few disadvantages to this approach. The "old stagers" among you know how many obstacles we had to overcome before the browser became a really useful operation system for writing applications. Just for the fun of it, let's start this article summarizing some of them:
- How to deal with the "back" and "forward" buttons in a web application?
- How to print a document from a web application? Most developers export documents to be printed as PDF files, but wouldn't it be nice to be able to print documents without this detour?
- How to import an Excel file into your application?
- More generally speaking, web applications run in a sandbox preventing access to low-level resources such as your computer's file system.
The gap gets smaller, but it's still there
Granted, we've learned to circumvent most of this limitations, and we've taught our users to live with the remaining limitations, but there's still a gap between native applications and browser-based applications. Browser based applications are always there, no matter where you are. At the bus stop, at the motorway restaurant, in the train, no matter where you are. But wait! At the motorway restaurant? That's not exactly true, at least not in Germany. And there are many tunnels blocking cell phone signals on the railroads, so the "always online" promise is vain, too.
You might say that modern HTML5 applications are capable of running offline. However, you can't evade noticing the pattern: we're solving many shortcomings of HTML that applications running natively simply don't have in the first place. Nobody's ever advertised a desktop application by saying "it can run offline". The only time you're talking about it is when it's not capable to run without server access. If you need an internet connection just to run Word or your favorite programming editor, that'd be a nuisance. Even if the advocates of cloud computing try to tell us something else.
The time is ripe to move load to the client
One of the most convincing arguments (at least in my eyes) is that there's much more computing power on the client side than on the server side. Again, that's something that isn't always true. In the poorer parts of the world low-key smartphone are very popular, and I wouldn't recommend ignoring that. Moving logic to the client may result in a lot of battery drain. However, in many cases my bold claim holds true. Most applications are used exclusively withing a company, and you know exactly which devices your users are using.
So there's that. Many (or most?) users still love their native desktop or laptop applications, because they result in a pleasant and smooth user experience. But many (or most?) developers have decided to use the browser as the operation system. How to get the best of both worlds?
Programming desktop applications natively
This series of articles shows a couple of alternatives. If you're coming from the desktop perspective, the first idea is to go native. That would be C# or the universal platform of Microsoft if you're supporting Windows. But this is a "Java and beyond" blog, to suffice it to say UWP is an interesting approach.
The second idea is to write a native application in Java. That'd be JavaFX for desktop computers or Android for mobile platforms. That's definitely an interesting approach, although the "all cloud" strategy of Oracle sheds some shadow on the JavaFX platform. We just don't know whether Oracle is going to support JavaFX in the future or not. However, it's not the first platform Oracle has dropped. JSF is a platform that used to be heavily supported by Oracle, but now the vast majority of changes are provided by the community. So chances are that JavaFX may be truly open sourced, too, meaning that the open source community (that's you, dear reader!) steps in if Oracle should falter.
Hybrid approaches featuring both browser and desktop UIs
Another idea is to write a server-side Java application, and run it on an embedded Tomcat or TomEE. That's what the second article of this series describes. I've used this approach for many years in production, so I can assure you this approach works. The programming model is a server-centric model, so it's a far cry from supporting the full power of the client platform. On the plus side, much of the computing power is shifted to the client, you can access low-level resources such as the file systems (albeit not directly) and you've got full control over your application's window. For instance, you can use the "F1" key to show the help text. Every browser I know prevents that by showing their own help screen. Wrapping the application in an SWT or JavaFX application prevents that, along with the back button and several other features provided by the browser that aren't helpful in an application that's not a website. As a bonus, I'll show you how to run an embedded Tomcat within the SWT browser window, so a lot of CPU power is moved to the client. Read the full story in the second article of this series.
Native programming using JavaScript or TypeScript
Those among you who are more into JavaScript or TypeScript may prefer another approach. Electron is a framework allowing your to write true desktop applications using HTML5, CSS and JavaScript. There are two popular applications showing how powerful this approach is: the Atom editor and Slack.
Hybrid approach using JavaScript or TypeScript
However, using Electron as a framework amounts to limiting your application to the desktop. That's may not match everybody's needs. Sometimes you want to write a web application which is also targeting the desktop. Fear not, there's a solution: Natifier is a promising tool to do just that. It wraps any HTML5 web application into the electron framework, making it look and feel like a native application.
React Native
When I hear about React native, I always think of native iOs and Android applications. But there are also spin-offs for Windows and the Mac. At the time of writing, I didn't try either yet. Judging from the number of commits, contributors, and stars, the Windows spin-off should work well enough, and the OSX spin-off has attracted a tremendous amount of interest, so I guess it's often used productively.
Wrapping it up
For some reason, many people seem to object the idea of using JavaFX to write their application. There are good reasons for this, but we shouldn't forget about the disadvantages of this approach. Just think of the lacking access to the file system, challenges to implement Excel imports or even simple things like printing. We've solved all these problems with HTML5, but I still think there are good reasons to package your HTML5 application natively. As we've seen, there are several options making your users' life easier: embedding the browser in an SWT or JavaFX window, embedding the Tomcat (or any other application server supporting an embedded mode), using Spring Boot and so on. For JavaScript programmers, Electron and Natifier are two interesting options, along with React Native for Windows and OSX users.