Over 20 years building, maintaining and managing enterprise applications, I came to have strong opinions on many topics. To take one, I definitely favor strongly-typed languages, as they will ease maintenance, and allow typial developers to ramp-up faster. Using standard technology with an open-source solutions is also a no-brainer for the enterprise context. You want the application to still run in 10 years, when the current fad will be over, and not pay forever licenses.
So when I started to build Open Lowcode, an open-source low-code platform, many choices were obvious. The application would be written in java, and use SQL for persistence. It would use parsimoniously open-source libraries, most of them from Apache. You may find those choices bland, but bland is exactly what is needed here for the rough life of enterprise applications.
Now, I had to make a decision on the client to use, and this one was the most difficult to take. To be sure, I wanted a thin client: enterprise applications are maintained very frequently, let's say a patch 2 times a month. I do not want to reinstall the client every time. The question was then: should I use the web client, or develop an alternative thin client ?
Web client seems an obvious choice at first, huge amounts have been invested by internet giants on various frameworks and technologies. Nonetheless, I ended up taking a different route for a variety of reasons.
I chose to develop a specific thin client (enterprise app) using javafx. The client displays pages that are made of high-level primitives exactly suited for enterprise purpose. This includes the famous spreadsheet-like interface to manipulate data in table, which is the 'killer widget' of enterprise software. As far as I know, and my research may be incomplete, such widgets are not really available, or very costly to make with web technologies.
Other benefits include possibility to limit data sent between client and server to a minimum, or to implement ad-hoc security tools when working in a military context. And I expect javafx to be stable in the next decades. One potential drawback is the installation of the software on the client computer, but this is adressed by making the client simple to install, and having an automatic updater.
Still, this choice is the one I am still hesitating the most about, and I would like to hear your opinion.
Latest comments (1)
Hi Neil,
thanks for the answer. For sure, the development on the client is partially transparent to the users. They would see the ergonomics that have been achieved, and the ease of deployment.
Do you have any example site to point me to regarding a nice spreadsheet like interface in ReactJS ? I would love to have a look.
The long-term discussion is interesting. I have the feeling that javafx would stay a stable niche technology (used for some business specific application) while web framework would be very popular for a few years, and then wane rather quickly as the next technology comes.
Another area for discussion may be the use of other client frameworks, such as, for example, the default Windows client technology, or a video game framework like unity.