>_Chaotic Java

So, why not Groovy, really?

· JavaFX

There's a lot of talk ever since JavaFX was announced around why Groovy wasn't enough and about the "conspirative Sun who never really liked Groovy anyway" trying to push it aside. So first, I think no-one is trying to push anything aside. If someone ever heard the phrase "the best tool for the given task" they would understand it the best - Groovy is not the best tool for the task of UI design. Maybe JavaFX isn't either at the moment, but at least that's where it's aiming, and Groovy just isn't. JavaFX comes with a few features that are extremely UI design specific, and I would like to reiterate them even though I've done this in previous posts.
  • Do Later: In JavaFX, you can tell the code to be "done later", meaning: To be added to the AWT event queue and be executed when the current iteration is finished. This is totally irrelevant to anything other than UI applications, thus will never be in Groovy or anything similar even though it is extremely useful.
  • Quick Animations: In JavaFX, you can tell a value to be set to an array of values using the dur keyword. This will set the values within a time defined, assigning values to the variable in a different thread which is in sync with the UI thread. This helps, together with binding, to create really smooth animations of movement, rotations, fading in/out of any UI element. Again, this has little if no use to anything other than animations in a user interface.
  • Binding and Inverse Binding: In JavaFX, two types of binding exist which allow to bind the value of a UI element to a property of one of the application's data model classes. In addition, it allows the creation of complex data models using the inverse keyword, which takes care of the synchronization of one-to-many and many-to-many relationships. Using inverse, it is easy to create graphs and trees for your data, later bound to the UI. Even though this is useful for any data model, binding is extremely useful for UI elements where a lot of work is done to keep the UI in sync with the data model without going crazy with all the Listener and fireEvent boilerplate code.
  • Creation of elements is UI-centric: In JavaFX, JSON is used to create UI elements. The behind-the-scenes engine takes care of optimizing the creation of these elements and their binding with the data model elements, so that it will be done in the most efficient way possible, be it pure JavaFX elements or Swing components.
In short, why not Groovy? Just like the FAQ says:
Groovy and other languages have two specific traits which don't precisely meet these needs, namely that they are generic in nature and don't provide the appropriate abstractions necessary to optimize the UI design process and similarly are designed specifically for programmers other than content authors.

Comments (4)

Avah
Also, as this guy points out, there aren't really Good bindings out there, and he says it himself: It's not because of Groovy but more because of the Swing/Java relationship. JavaFX does for UI and replaces the developer's interaction with Swing just like XAML replaces the interaction with WinForms or Interface Builder replaces it for Objective-C. It's UI-oriented, and it will have UI-oriented tools built around it. And that's the key point, I suppose: The tools.
Tom Palmer
So you haven't heard much of easy DSLs? It would be easy to say "doLater {somethingOnEdt()}" in Groovy. Probably not more than a few lines of code to implement. Search "Groovy SwingBuilder" at Google for the JSON-like issue. I reckon "dur" is also easy to implement. All that said, I'm not so sure the binding is easy in Groovy. My understanding is that would could be improved. JFX Script has other features, too, but they're not so central to UI development (such as implicit static typing and so on). In other words, add a bit of better data binding to Groovy, and all your points are covered. But making new languages _is_ fun ...
Avah
It's not about whether it's easy to implement or not. It's about whether it's easy for UI developers (who are completely different people from regular developers and generally have very little coding skills). Brings me to a rule-of-thumb: People who write code should not design the UI. It's just that.. Most people who develop are not UI people. And UI people... Well, they just don't know how to write code. So why make it complex for them? Look at the amount of work done with separating code and UI, with XAML on Windows, NIBs on Mac, and now JFX through JSON in Java.
xeye
Most ppl who design UI do not write even simple scripting code, so I don't see why groovy is more complex than FX to them... I guess, if there's existing person who create UI he/she probable will not study new language at all and stick to something known.