JavaFX Coding Challenge
Third Place Winner Evgeni Sergeev shares his thoughts
- Evgeni Sergeev submitted the ShiningEtherFX Application that won Third Place. Evgeni shared some detailed comments with us:
I should start from my very first experiences. From the name, "JavaFX", I expected it to be something like a new toolkit for Java. So when I looked at the source code of the examples, I was surprised that I couldn't read it.
Of course, everything you can do with JavaFX, you can also do with Java. This is somewhat in the same way that everything you can do with Java, you can also do with Assembly! Well, maybe not so drastic. But JavaFX introduces a few powerful features which are applicable everywhere, therefore the whole coding style changes when you go from plain Java to JavaFX: the binding semantics, the implicit generalised constructor, the functional-programming-like expressions, the list as a first-class syntactic citizen - all these permeate JavaFX source code.
I had a look at the code of an applet which I wrote in plain Java last year, and then I didn't think of an event model as flexible as the one that JavaFX provides. I put the reaction code right into the event handlers. And, since, in general, there is a many-to-many relationship between actions and reactions, that applet now looks difficult to extend. For example, in many applications, controls must be enabled and disabled as the user switches in and out of various modes.
Well, thinking in JavaFX, that's a trivial thing to do - we would bind the "enabled" variable of each control to a logical expression determining when it should be active.
Before I thought that way, I would write a centralised function, such as "modeChanged()", in which I would set "enabled" on each control via a logical expression.
The problem with that is, when adding a new control, I would have to edit the centralised "modeChanged()" function, so I now would have references to the new button in two places in the code, far away from each other.
When everything is done that way, not just the enabling/disabling functionality, it becomes UI spaghetti - references to the one control in a dozen places.
With JavaFX, it's possible to keep almost all of the code for the same control in one place.
The "bind" semantics are fantastic. It actually does what one would imagine "bind" would do. That must save tons of boilerplate add-listener code, and, also, to implement something similar in plain Java, one will have to take care of event-firing code too.
So, for my last year's applet, I could have used a JavaFX-like approach, but I didn't think of it, I just did what appeared to be OK in the setting of plain Java. If I used a JavaFX-like approach, there would be a large number of listeners and event dispatchers everywhere, mixed with the application logic.
JavaFX makes certain good design choices the obvious ones to take, thereby encouraging good design, by virtue of the way its syntax and semantics are.
The applet that I wrote for the JavaFX Coding Challenge took less time to write (and has a similar number of lines of code), but it has much broader functionality - because the effectiveness of JavaFX left me enough time to put it in. I also feel like extending my JavaFX applet once I find a block of free time - because I know that I can add self-contained controls, without having to edit the code in a dozen places, so I'm quite confident that it won't break. Even now that I haven't looked at its source code for a few weeks. I'm sure that very large applications written in JavaFX could be as easy to add to, as smaller applications.
A great consequence of the syntax and semantics that JavaFX provides is that simple things, like rollover buttons, could be done in one line of code, without having to add MouseMotionAdapters or such like and implementing its methods - that might be five lines or more in plain Java, so it often is not worth the effort of putting in.
On the first day of trying JavaFX, I was confused and disoriented, but I looked at the examples and their sources, and was making progress. Some things are quite foreign - looking at one of the examples, say the DisplayShelf, well visually it doesn't look like your ordinary Java applet! And the first thought that comes to mind is: someone has spent a long time making Java do this. But then look at the code - it's really quite simple and to the point. On the third day I realised that JavaFX is actually the best UI tool I now knew.
Besides the syntax, there is the API, which is also highly important where user interfaces are concerned. It's fun to use, because you've got the scene graph to work with. In plain Java, I would have been thinking in terms of the paint(..) method, or paintComponent(..), when should I be repainting an element, etc. But all of that disappears with JavaFX. I am thinking in terms of adding and removing elements from the scene graph. I can add items to a Group, and then move the Group around. I love the way that animations are integrated with the scene graph - whenever I move an element by changing its X and Y values, I could just as easily substitute an interpolator that will change X and Y smoothly.
It's a rich platform. For example, the SVGPath. It's a nice-to-have feature. I drew a simple icon on a grid inside Inkscape, copied and pasted the SVG string, and it's already inside my JavaFX applet! The process can hardly get easier. And that's the important thing - when developers begin to feel that what they are doing could, in principle, have been accomplished in a more straight-forward way, saving mouse clicks, intermediate files, copying and pasting filenames, etc., they feel unduly burdened and averse to all the unnecessary overhead. In many cases JavaFX's expressiveness allowed me to approach the maximum conciseness when stating the rules I wanted to put in my application. Bind clauses often read like sentences in a natural language. A complex logical expression could be reduced into several named parts by defining bound constants with meaningful names. JavaFX code can be made very readable.
Overall, my experience with JavaFX was highly positive. I felt that it was written with user interfaces in mind, to make life easy for the developer, but it's not just a collection of useful features. There is a purpose-driven underlying logic that has lead to a small set of new, widely-applicable concepts, reflecting the thinking patterns of the UI developer. I believe that after some critical mass of developers engage with JavaFX, its ideas will begin to have a major impact on other user-interface design tools. I will certainly be using JavaFX for all my UI work wherever the context allows.
JavaFX fills a gap in the Java family, and it does so powerfully, raising the bar in the UI design tool arena.
Learning JavaFX gave me the same sort of feeling as learning Python's lists after the STL, or learning regular expressions after parsing strings with charAt(..) and if-then-elses.
JavaFX is a platform with a big future. It is young, and it is competing with a strong product, but it stands on a firm foundation and it gives the UI developer many of the things they always wanted. JavaFX UI code can be very tight-knit and readable, and I think that a developer who has committed a week or so to get used to JavaFX, would be reluctant to go back to whatever they were using before. However, customers will keep asking for "a Flash website", and that can change only very slowly, unless JavaFX is boosted by acquiring a capability that Flash does not have - that is, from a customer's perspective.