It has been a dismal decade for desktop application development. With web frameworks sucking all the oxygen out of the desktop world, the choices for desktop development are incredibly unsatisfying. Back when text-driven interfaces were the rage, we hit the peak around 1990 or so, and the first GUIs started to take hold — ugly, sluggish, bloated things that (while they had certain advantages) would not really capture the speed and cleanliness of the TUI for over five years.
So when client development started moving to the web, I figured it would be a while before those interfaces caught up to the height of the GUI — and I am still waiting. We have the bloat, a fair amount of ugliness (though certainly some amazing design work as well), a fair amount of sluggishness, and for sheer usability, let’s just say it’s a pretty mixed bag. I suppose the world is moving away from straight data-entry anyway, toward a non-written world where everything is icons, speech-to-text and brain implants.
But in the now, some of us still use desktops and would like to make nice looking, responsive, multi-platform applications, and the prospects are not great. This poor sap wrote a lengthy article on the topic, starting quite the squabble to which I will basically add: Yeah, more or less.
Who Am I?
I’m just an ordinary joe, a working man trying to make his way in an increasingly parlous and contentious time. But more to the point, I’m a guy who’s been programming longer than you’ve been alive, who has an app to write. In the past, I’ve used a lot of Delphi, which was really the king of Windows desktop app development (and still is). If you wanted something done fast, done right and done pretty, it was your go-to.
The project I’m eyeing currently supports a small business (support for the software) and a bunch of other small business owners, and it was written in Delphi, so the obvious thing would be to upgrade it to a newer Delphi. But it has the problem that so many Delphi apps I’ve seen have: It hasn’t been updated in so long that just getting it to run, with all its various components needing upgrading (which at least still exist in some form — not always the case with these old Delphi apps), is probably harder than just rewriting it.
And I say that advisedly, as the coder I inherited it from, who had been working on it for over a decade, tried for months and failed.
Delphi
Delphi was declared D.O.A. more-or-less on arrival 25 years ago, and despite the premature declarations, it may have finally fulfilled the destiny, at least for the professional. It peaked in 2002, with Delphi 7, and has never really recovered from the disastrous Delphi 8+. I have not used a version in the past 15 years that did not present me with weird exceptions, and while they swear to the speed of development, I find the whole code->compile->run process shockingly slow. (Perhaps because I recall the instantaneous days of Turbo Pascal 3.)
I could wax on about Delphi, having used it for the full time of its existence (and then some!), but there are a number of deal killers for me. I hate to say that it’s “too expensive”, but for something with no job opportunities, it is. I could use it entrepreneurially, but if I’m not going to code everything myself, I have to subject employees to spending their time on it. So I can’t get a job doing it, and I can’t hire people who know it, basically.
Even so, I would consider it except for two other major factors: Since the 2000s, a huge portion of what we do as developers is assemble software others have written; since the 2010s, a huge portion of what we do as developers is solve our problems by finding the exact issue online and applying that answer directly.
So, while Delphi has Firemonkey, which is pretty cool as a cross-platform GUI, you won’t find a lot of answers online when you have trouble, which will be always. (Checking on StackOverflow right now, e.g., there has been an average of one question per day asked about Firemonkey for the past two weeks, which is an uptick. By contrast, ten questions about JavaFX get asked every day.) And this is just about the GUI framework; other functionality you can virtually take for granted in any modern ecosystem, you will have to buy in Delphi — if you can find it. And Delphi’s component system, while relatively cool at the time, is seriously clunky at this point.
It’s a shame, because the Golden Age of Delphi was very productive indeed, and I don’t know if we shall see its like again.
…and the rest
I’ve always kept my eye on advancements (mostly dead-ends, if we’re being honest) in the Desktop UI field. I have done Swing, wxPython, Flash Builder, Visual Basic, Electron, and a bunch of things you’ve never heard of, and they’re all pretty ugly. Some on a visual level and some on a technical level. (I understand Electron’s seductiveness, but what a big.)
QT is not necessarily ugly, but it is extremely complicated to my eyes. And super-expensive. I hate to bring up expense because anything that saves a coder time is going to be worth the money, but I’m working with something close to a zero budget.
There is a chicken-and-egg thing going on, too. If I can update the app, I can get more money from the customers, but until I update the app…
As the Royal Sloth discovered (in the above-linked article), there are no good answers. Which brings me to JavaFX. And the purpose of this series of articles.
JavaFX
It is possible to write a good user-interface in Java, even though it’s only been done once. JavaFX came along to make it easier to do things that looked good and when I started down this road, there was a lot of shakeups going on in the JavaFX world, but the upshot did not appear to be that the library was going away.
I’m not a huge Java fan. Part of me, as an old-time Smalltalker, wishes that the (now mostly extinct) companies peddling Smalltalk had gotten their acts together and made a deal with (the now extinct) Sun and given us a good Smalltalk (though they exist yet!) but Java is what it is, and what that is is the stodgiest language this side of COBOL.
In fact, I started down the JavaFX road in Clojure, a language I find very productive. And I hope to return there down the road, but I discovered that the JavaFX libraries in Clojure tend toward the highly opinionated, meaning that not only are you tackling JavaFX, you’re tackling the person’s idea of how data should be manipulated in a JavaFX app.
I’m not even saying they’re wrong. I’m saying it’s a lot to swallow at once. And when you get in trouble, getting help isn’t going to be as easy as looking for the twelve other guys who had the same trouble as you and posted duplicate questions on StackOverflow.
After abandoning Clojure, I went to Kotlin, which features TornadoFX, a language-specific library for interacting with JavaFX and that had a very cool feature of allowing live fiddling with your UI — Clojure has this too, by the way — only to discover that the Tornado runtime features are completely absent from IntelliJ. JetBrains, makers of IntelliJ, Kotlin and (I think) Tornado, has given us a blank set of options when running TornadoFX apps.
Again, see my point about “where do you go when there’s trouble?” And I probably should note that for the first 15 years of my career the answer was “the manual”. Or, “you figure it out for yourself”. (One of the great things about simple, non-opinionated Clojure libraries is that “figuring out for yourself” is much easier than in, say, a drill-down, thickly hierarchical object pyramid.)
I have devoted many, many hours to obscure technologies that more-or-less evaporated in time (ReXX, anyone?) and for once, I wanted to be popular. Or be popular-adjacent. So, straight Java and JavaFX it was going to be, at least until I got enough under my belt to maybe build out my own solution.
Life Among The Technical Manuals
But there is, alas, another wrinkle: The quality of programming books. I’ve basically stopped reading Packt publications because there’s no guarantee that they’ll be in English. And way, way too many authors think “Printing a table with the API and a short example using parts of the API teaches the user how to use the API effectively.”
I can’t begin to count the number of times I’ve read the API for a button, nor in how many different libraries. And the number of books I’ve looked at that do little other than provide a slightly different (and not always even that) example than the official docs.
I’m currently reading The Definitive Guide and while it’s the best of what I’ve seen so far, covering a fairly broad spectrum relatively deeply, the “deep dive” into the components, e.g., is a well-constructed-but-shallow look at every single basic component. In practice — when you’re actually building an application — understanding the API is a trivial task compared to figuring out how to fit the pieces all together.
That is, you can get a lot more out of even a dumb, actual example than from all the lists of APIs in the world. But nobody does this. And they don’t do it, because it’s hard. I speak from experience here: Trying to construct even a trivial app and explaining the thought processes along the way, while also going back to re-edit and put things in better places without breaking everything that comes after is one of the most challenging things I’ve ever done. It’s like debugging a dictionary. Or a crossword puzzle.
The Story of Western Civilization, or, My Life
My solution to this is going to be to write a program “live”. I’ll build a simple app — though not too simple — that plays some games (and we’ll stretch the definition of “game”), and works through the various issues that come up.
I’ll jump around a lot in terms of what parts of the API I use because that’s kind of how real life works. So, I’ll be using FXML and Scenebuilder to load simple screens with buttons, but then I’ll dip into the effects bin to transition between screens. I’ll try a very simple, purely graphical interface but I’ll hook into the drag-and-drop. And so on.
I’ll make a lot of mistakes and say a lot of stupid things, as always. But in the long run, hopefully we’ll end up with a useful document that people can actually read and learn JavaFX against.
But for now, I’m going away from all things electronic for about two weeks, so I’ll see you in April!
