This following blog presentation is also available in audio as an AudioBoo: "Why Should I Invest in Learning JavaFX?".
What functions does your customer or business analyst want to see in the final application?
What are your project's aims?
Do you want an application with richer graphics, such as advanced 2D and media support?
If so, then a rich internet application framework probably suits you better. Any of JavaFX, SilverLight, Flex will do, then you must drill down into the user story and capabilities of each.
Does your user story restrict your project to HTML standards, in particular HTML 5?
If so, then choose an AJAX framework, Dojo, JQuery, Ext JS and an appropriate Java Web Application framework. From there you can drill down in the technology, which best maps to your user story.
JavaFX, even at its 1.2 release, probably at this point is better way of building a Java Applet, because I do think it is the future of client side Java UI. It is much easier to build an application front-end quicker in JavaFX, because of it declarative nature code, and because the language support binding and triggers.
I bet there are lots of you who are very experienced with Java Servlets and some of the earlier application framework build around the former's API. I believe that JavaFX feels like Struts 1.0 (circa 2001) at the moment to me in my opinion, in that if you get involved now you are still ahead of the curve, rather than six months down the line when, probably, everyone else will come aboard. In other words, I do believe that FX will get substantially better, because the community writing code and components as well as Sun developers. Also the platform is becoming more stable as time progress, the standard APIs and the concepts settle down.
The biggest differences between JavaFX and Struts touchy-feeling thing are
- The huge codebase in JavaFX in comparison to Struts 1.x.
- The life expectancy and the goals for JavaFX
- The FX runtime is not open source, but the compiler is.
Let us deal with these in turn.
The Huge Codebase in JavaFX in Comparison to Struts 1.x
The original inspiration for FX was Christopher Oliver, F3 project way back in 2006, 2007, where we invented an interpreter called Form-Follows-Function. He was a Swing Developer, who wanted a faster way to build GUIs. So he thought about creating a little scripting language (obviously) to speed-up Java user interface development.
Here is a decent article http://research.sun.com/minds/2008-1202/
Chris Oliver blog http://blogs.sun.com/chrisoliver/
So this simple interpreter, a proof-of-concept, with a much smaller codebase, eventually became the JavaFX runtime, the statically typed language compiler and scene graph and much more. The result is a explosion of the size of the entire code base, and if you have read Fred Brooke's book, about throwing programmers into a project. Well you already know the answer. The software takes as long as does to get right and no sooner than that.
In comparison Struts 1.x had lesser lofty goals. Tomcat already existed at the time and there was a Servlet standard API to use. You might disagree about the overall analogy and be that as it may.
The Life Expectancy and the Goals for JavaFX
If you are going to produce a new JVM platform extension, then that takes time to envision and produce. You have to build a little bit, then test it, then build it again and then test again. Every project in the planet suffers from this reality versus implementation goals from Google Wave to JavaFX to the Linux Kernel. It just happens that Rome was not build in a single day.
I believe the lofty goals in JavaFX were / are / are going to be:
- Complete Chris Oliver's original vision, make it easier to write GUI applications in JavaFX in comparison with Java Swing.
- Update the technology of the Java User Interfaces on the desktop. A scene graph is ultimately much better than the old fashion way of immediate-mode
GraphicContext.paintEllipse( x, y, width, height );
In comparison, JavaFX needs only the component and a container to be declared.
centerX: 100 centerY: 100
radiusX: 50 radiusY: 25
fill: Color.YELLOW stroke: Color.BLUE strokeWidth: 3
- Create a better Java based scenegraph allows nodes to be transformed: translated, scaled, rotation with high performance.
- Fix the Java applet and web start client runtime
Changing from immediate mode to scene graph node mode, at inspection, implies a performance penalty, at least from software engineering architecture, because it is one more layer of indirection between the graphics primitives being the sent to the GPU. Ultimately, Sun, need to solve the performance of rendering 10000 of nodes (in future applications) to the desktop. Pick up any computer graphics book (written by like Foley, McGregor and Watts) and you will see algorithms like Sutherland Clipping and Z-Order sorting. One, then, needs to read up and hardware accelerations books and more hard-core books to figure how to program Direct X and Open GL GPU instructions. This is the runtime part of JavaFX platform that also benefits normal Java developer as well, because improving 2D performance ulitmately benefits both.
- Push the compiler so that optimises the JVM considerably
Then there is the FX language compiler. The current JavaFX language reference is quite different from Chris Oliver original F3 interpreter. You will find that Brian Goetz, author of Java Concurrency and Practice, is working alongside Per Bothner, a language compiler wizard to get the compiler doing nice things. Compiler is now producing decent enough byte code such Hotspot in the Sun JRE can do the rest.
The FX Runtime is Not Open Source, But At Least The Compiler Is
Up until May 2008 the runtime was open source. I think the scene graph project was also open source, at one point. Around 15 months ago (May 2008), an executive decision was taken to bring the runtime back into close source. The development community outside Sun were excluded from seeing the changes.
On the one hand this is fair enough. It means that Sun can design the runtime and scene graph quicker without interference. This should not be upsetting to anyone at all. After all it is their business and companies are allowed to develop close source software. Google, did it with Androidand is doing it with Wave, until they decide it is ready for a release. The move was not illegal. It was some what surprising that the early access changes disappeared entirely.
On the other hand the decision to not release often or give clear guidance what is happening with certain design decisions has, in my opinion, hurt the JavaFX project and community a little. For example, I wanted to get a component design guide, and I asked for this, yet no one from Sun could provide one. So many developers stumbled trying to create their own components. We invested in a lot of time, experimenting with the released or open parts of the JavaFX platforms. Obviously, components are those GUI elements that are needed now, if Sun Microsystems want to compete with Flex and SilverLight in the markets. It did not make sense to me to provide only fleeting support for those early JavaFX adopters.
Having and said all of this, I realise that writing a runtime, compiler and scene graph, and get all of this working on a desktop, mobile (and let alone TV platforms) profiles is flipping hard. I believe Sun need more openness in overall design and they need to engage the community a lot more.
Examples of User Community Work
If you want to see more user-contributed components then have a look at my Nelson Framework examples (http://www.jroller.com/peter_pilgrim/entry/the_nelson_framework ). (These are FX 1.1 examplese and I am current re-engineering the Table UI component). My open source project is on Kenai (http://kenai.com/projects/nelson )
Then there are dozen's of learning articles and blogs at there too - http://learnjavafx.typepad.com/weblog/
And the official JavaFX tutorial which is is *strongly* recommended for complete FX beginners.
In conclusion, the future can only be brighters, because there are enough passionate JavaFX developer who believe in the platform and the mantra "reinvigoration of the desktop". We now need better communication, more release often and a bettter guidance.