disclosure: the opinions shown at that article have nothing to do with my current employer, they are my own.
Will probably raise some eyebrows with the following paragraph
"The platform promises a lot of new APIs and new abstractions to make the harder things simpler and the simpler things very easy," says Almiray. For example, APIs and libraries take care of establishing the correct order of a drawing on the screen, he notes. JavaFX Script does offer some features not in Java, such as data-binding into the language, Almiray says. But he notes that some Java features -- such as annotations, generics, and inner classes -- are lacking in JavaFX. Almiray expects that JavaFX will succeed in the mobile arena, but says it will be tough to compete with Flex in rich Internet applications.
Let's walk through it step by step. It's true that the new APIs facilitate working with Java2D/Swing, the SceneGraph API (though yet unfinished) changes the paradigm of how drawings (and even Swing apps) can be composed. They are also tool friendly (plenty of getters/setters, bean-like approach).
About the missing Java5 features (already received some flame @ dzone because of this comparison), the important thing is that if JavaFX Script succeeds then Java developers will use it. Java developers are already used to those Java5 features, so what will happen when they find out that not only do they have to switch language but also programming paradigm? Personally I think it is a Good Thing, but as the previous discussions on Polyglot Programming there are plenty of voices against this approach.
Lastly I really don't expect JavaFX to succeed in the mobile space unless Sun concentrates its efforts on that space. Touting JavaFX as a RIA Platform while at the same time aiming for the mobile arena will be an uphill climb, a very steep one. Simply put, there are 3 known profiles in JavaFx: common, desktop and mobile. The mobile one is actually the one driving development of the other two, as it is the most restricted one (Swing can't run on it for starters), which is why many already existing Swing components must be rewritten/ported to the common/mobile profiles. Wondered why threading issues can't be solved by subclassing SwingWorker? yup, same reason. SwingWorker will probably not be able to function in the mobile profile without some tweaks, which is why there is already a fix in the works for all profiles.
Besides nobody can fight two battles at the same time and expect to win them (unless it happens to be Chuck Norris).
