javafx 2.0 - great progress, some thoughts...

I looked at javafx 2.0 beta and I am very pleased with the progress. I think Oracle could make a great steward for some java technologies especially if they can make it economic so that more investments in java can be made.

I took a look at the programming model, which is based on the idea of directly programming a scenegraph, and here are some thoughts:

• I liked the programming model as compared to Swing. There are significantly fewer "model" constraints" I am a fan of less API for models. Swing always had complicated models for more complex controls. fx2 has fewer.
• More integrated thinking about effects and rich media. That's all good.
• CSS: I'm not a big fan of CSS for UI presentation specifications. Why? Well, first, you are typically using another "language" even if it is a DSL. I think WPF had it right in that that built the CSS-like stylers directly into the language and XAML supports the same "syntax" for specifying CSS-like effects. You don't have to learn two things to use. You can debate the use of XML of course, but its unified. I know everyone thinks that CSS is great because it is so widespread, I think it is not so great because it's yet another thing that sits outside all the frameworks, is still not standardized, and requires more learning and tooling in addition to the actual UI framework. Personally, web UIs (html, rias, 1/2 rias) are in quite a state of disarray.
• fx2 worked the first time I tried it. That's good and it was not hard to get started with fx2 at all.
• It has a more advanced property system than just standard pojo. That's very good. Its based on observable values, so its mostly consistent with jgoodies and eclipse databinding.
• It has a XML language for specifying the user interface. That's good. Its just built wrong. Its built like pivot's and not like XAML. I wrote a XAML processor called XIML. It should use something that is more standardized, has less one-offs and is extensible. It should also allow node stream filtering like XAML "services" does in .net4. Just a pure XML reader is bare bones and more could be done that would support better tooling scenarios and easier ease of use.

Where my concerns come in is around strategic direction. Have other toolkits been scanned and their best ideas incorporated? Ideas that I think really stand out and speak to innovation (even if it was several years ago) include WPF-like features:

• The concept of templates versus the API-model cell factories. The cell factory API in fx2 today is still very API heavy compared to what it could be. Templates are not new thinking but how they are integrated in to the UI model for WPF is very innovative. Can fx2 advance that and demonstrate innovation? Right now, it feels better than Swing but still very Swing like in terms of its strategic model for improving programmer productivity. Think of having a defmacro capability for UIs and you don't need lisp. Having templates means that you do not need the "skin" implementation pattern. Also, templates are a well known pattern for web programming e.g. Velocity.
• Templates or factories should also be used for specifying panels inside complex controls. It should be possible to replace the panel (which means layout) of a list control simply and have more choices than just vertical or horizontal. This is an example of here the use of binding and templates can help loosen people's tie to older Swing UI technologies. This is also a perfect example of where old style Swing thinking enters in versus parameterization and plugability.
• There are still places where the library is API heavy. Everywhere where binding can be used, it should be used in order to decrease API requirements and have less "model" specifications. Swing had many model assumptions so writing adapters on top and other frameworks always had to know the nuances of how they worked to make their code work with it. WPF often has some binding-API-like requirements but they are much less onerous. Swing's controls all had models some very advanced. Its impossible to avoid some API but lets think of binding for everything so that the API for models is decreased as much as possible. The cell API is one example.
• The property system, based on observable values much like jgoodies is fine. However, some of the property system should be uplifted to the class level instead of property level. This allows all of the properties to be managed more efficiently and more metadata included in the property system. The current system also needs to allow generic set and gets using properties identifiers. While this can be simulated via reflection, it would be better to allow this model to begin with. This would also allow attached properties which are a basic lisp concept that has great value in UI framework as proven in pivot and WPF. You really do need a setValue and getValue method that works where the "property" is a parameter. This is why EMF has this model (in Eclipse although EMF is independent of Eclipse).
• Swing always stopped short of providing the last mile to your pojos or application objects. I don't want fx2 to make the same mistake. For example, many domain objects in applications are pojos with standard properties or maps. Lets make sure its easy to bind to those types of objects by providing adapters similar to jgoodies BeanAdapters. Make these available out of the box. In fact, the concept of the BeanAdapter is missing in the fx2 toolbag and needs to be there to allow to have observable values/properties that operate against any bean even when you switch the bean of interest. Yes, I know that making this last mile easy typically means that you trade-off compile time checking versus "string" property name specification, but you don't need to make this trade-off black or white. With solid engineering and including the easy approach to these features, you can have BOTH. Make it easier for programmers!
• Use a hierarchical (across node parent-child relationships) data context for default binding. Yes, you could program your own but in the spirit of making the last mile easier out of the box (with solid engineering underneath) versus prescribing more specifics about an application should be constructed, make a default data context and have default data binding against it. It just saves oodles of effort.
• fx2 should move in the direction of thinking of "containers" and resource management similar to WPF. WPF is actually very similar in concept to dependency injection containers and resource management (creation and lookup). Except WPF still wasn't thinking about that completely but its closer than other UI framework have. These are powerful implementation patterns in that they can be consistently used to create many different types of frameworks on top of it as well as provide flexibility when you want to change things or integrate the UI with the domain part of your application more seamlessly. Think of using spring framework ideas to compose the framework--that's the kind of thinking you want.

Those are just some of my thoughts. I really want to see an incredible focus on programmer productivity much like what WPF does but with solid engineering behind it so the guts can be replaced in case someone wants to do that. I'm also not saying that WPF is the only way to go or does everything well or its APIs are the best. Only that certain features it has appear to improve programmer productivity and I have experienced greater productivity when programming WPF.

However, out of the box, in additional to the underlying engineered API, it is safe for fx2 to make more assumptions about how applications operate to provide one "version" of last mile support for applications and their domain objects. The great part about java is that it can be better engineered down under but still provide strong last mile. That's always been the problem with other UI frameworks based on java and what WPF got right.

What can they do to do that? Take the top 100 use cases and optimize the coding path to make them work. Figure out the non-programming parts: how to keep everything API consistent through binding versus programming API.  Then ensure that there is solid engineering underneath so that the machinery can be changed in case you fall outside the box.