I suppose for many it was just another unremarkable mid-May Wednesday; certainly I don’t recall the weather making any effort to surprise. What might have made the day slightly memorable for some, perhaps, was that Manchester United was playing Chelsea in the final of the ultra-prestigious soccer European Champions League. A couple of days earlier I’d returned from a few weeks’ sampling of random pubs and music clubs in North America, starting in Los Angeles (actually, starting in Dublin, Ireland, but I’ll not complicate the story) and ending in Vancouver. Now I sat in front of my TV, hoping, somewhat optimistically, for a 3–0 destruction of United, to round off the perfect holiday.

And that’s when the phone rang.

Mike Stephens, associate publisher at Manning Publications, was on the other end. Earlier that day he’d emailed me to request a one-to-one, and, bang!, on the agreed time, there he was! Over the next 60 minutes or so I hardly noticed any of the game. We talked about Java and the way the industry was going, and inevitably the topic drifted toward JavaFX. At that time JavaFX was still in an embryonic state: features were being added, evaluated, and then modified or dropped. Anything and everything could change with each prototype release. Yet, to me at least, the ideas behind JFX showed great promise. If enough backing was put behind the project, and with a fair wind to guide it, I thought JavaFX had the potential to really shake up the whole front-end (user-facing) rich internet application market. With those sentiments in mind, some weeks earlier, I’d blogged about my early experiences—good and bad—with the platform on java.net.

I’ve always had an interest in computer graphics. I consider myself fortunate to have been born at just the right time to catch the wave of 8-bit computers that swamped the market in the early 1980s. The Commodore 64 was the first computer I owned, a machine with truly overwhelming potential and decidedly underwhelming documentation. Thankfully the version of BASIC that shipped with the C64 was only half finished—I say thankfully, because it meant wannabe programmers like me had no alternative but to learn the mystic black arts of machine code hacking and metal bashing (programming the graphics and sound chips directly).

As the 8-bit era gave way to the 16-bit era and then the 32-bit era, graphics programming became ever more removed from physical hardware. Bashing the metal was discouraged in favor of multiple layers of software abstraction. Not that I objected; I understood why these changes were necessary, but they did take all the fun out of programming. Compared to the instant gratification of the poke’n’peek 8-bit days, modern graphics programming was more like a huge exercise in complex logistics.

Scene graph-based graphics systems put the immediacy back into UI programming: the coder no longer worries about how or when the screen will update, just what goes where and how it should all animate. Yet I considered that only part of the solution. None of the popular programming languages was specifically designed to tackle the unique circumstances in graphics programming. When the likes of Java or C# did introduce new language features, they tended to be for the benefit of web frameworks or database programming, not pixel pushing.

But JavaFX was different. It was a clear—and unashamed—attempt to build a product optimized for slick graphics and media. Not only did it use a scene graph, but it had a programming language tailor-made for creating modern UIs and animation. The perfect marriage of these ideas, for me, was what really set JavaFX apart. Someone, somewhere, cared about coding beautiful UIs as much as I did and wanted to make it fun again!

Suffice to say, by the time the phone call ended, Mike had talked me into writing a book about JavaFX—although, to be honest, I didn’t really need much persuasion. Oh, and Manchester United beat Chelsea, 6–5, on sudden death penalties. I guess you can’t have everything!