Sunday, August 23, 2009

Flex 4 vs JavaFX 1.2: Dance Battle

I make it a point to follow Chet Hass on his Codedependent blog. He always has something interesting to say about features in Flex. Even though I rarely use Flex, he often demonstrates interesting animations or visual effects.

His latest post talks about the new transform effects in the upcoming Flex 4. Specifically he uses move (translate), rotate, and scale transforms to manipulate a control and make it twirl gracefully across the screen. Ok, that's a stretch, but I had to work the dance thing in here somewhere. You may want to watch his demonstration video now.

When I saw the MXML code that Chet was using for his demo, I was struck by how similar it is to the way I would accomplish the same thing in JavaFX. Below is Chet's Flex 4 demo code:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx=""

        <s:Parallel id="transformer" target="{button}">
            <s:Move xFrom="50" xTo="150" autoCenterTransform="true"/>
            <s:Rotate angleFrom="0" angleTo="360" autoCenterTransform="true"/>
            <s:Scale scaleXFrom="1" scaleXTo="2" autoCenterTransform="true"/>

    <s:Button id="button" x="50" y="100" label="Transform Me"

And here is the same thing in JavaFX 1.2 formatted to emphasize the similarity:

import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.animation.transition.*;

var transformer:ParallelTransition;

def button = Button { layoutX: 50, layoutY: 100, text: "Transform Me"
    action: function() { transformer.playFromStart() }

transformer = ParallelTransition {
    node: button
    content: [
        RotateTransition { fromAngle: 0, toAngle: 360 }
        TranslateTransition { fromX: 0, toX: 100 }
        ScaleTransition { fromX: 1, toX: 2 }

Scene {
    width: 400
    height: 300
    content: button

And here is the JavaFX application:

Some points of comparison:

  • MXML and XAML always lose me at xmlns. I'll take import statements any day, although most IDEs will manage XML namespaces and import statements for you. In general I simply prefer writing my declarative code in a programming language rather than a data interchange format - no matter how Flex-ible it is.
  • Deployment in a browser: Flex wins. Period. The deployment team at Sun has done a lot of work to narrow this particular gap, but Flash is still everywhere and it just works. I fully expect some significant number of people to have trouble running the applet above. And applets still flicker when the browser scrolls. Not serious, just annoying.
  • Flex has a slight edge in brevity, I think. But in return for some extra characters, you get all the benefits of static typing. The JavaFX compiler can catch syntax errors for you and IDEs will flag them immediately without having to run the program first. IDEs can also support much more robust refactoring and code completion (at least in theory, hopefully the Netbeans JavaFX plugin will finally get some more attention soon).
  • It seems odd that previous versions of Flex couldn't display text on a rotating control. And even these new transform effects have some gotchas to watch out for; like having to set autoCenterTransform on all the effects since they manipulate the same data under the covers. Not that JavaFX doesn't have some gotchas, but for the most part the foundation is solid. This kind of thing always surprises me when I hear about it. Flex is supposed to be way more mature, after all.
  • The JavaFX code above works on mobile devices (like the HTC Touch Diamond shown to the right) as well as on the desktop and in a browser. I'm just saying.

Twirling controls aside, you obviously can't make a definitive comparison of two competing technologies based on such a simple piece of sample code. I found it interesting how similar the code actually was between the two platforms. Hopefully you did too.


  1. - MXML: Agreed. XML sucks for programming. For visual tools, JavaFX Script is just as well designed. For human reading/writing, XML saves a bit of space if densely laid out, but even with more generous spacing and indentation I find it much harder to read (this example is HelloWorld size; a real app would blow your brain up in MXML). A does-it-all syntax cannot compete with a dedicated DSL, that's not even debatable.

    - Deployment: I tested both versions and I really couldn't tell any difference. The JavaFX applet has a warm-start time below 1s, the same as the Flex app (which is definitely NOT in the 100-200ms startup you can get with tiny Flash apps; Flex is showing its weight here). The single thing hinting that JavaFX runs on the JRE is the stupid Java loading animation. Oh, and no flicker here for JavaFX. But then, I'm running JDK 6u18-ea which contains another batch of important JPI/Applets/JavaFX optimizations; won't have the trouble of reinstalling 6u16 to see if it performs worse in this particular applet. Also, I can't compare cold-startup times because Chet's blog contains a video that takes a lot of time to initialize in parallel with the Flex app. In summary, Flash is only better in the deployment part because the runtime is more ubiquitous, and when not present it's a smoother install.

    - Mobile: Definitely a strong advantage of JavaFX. Of course this depends on the extent of Sun deals with device makers; the public partner list is still modest with only LG and SonyEricsson, but now with Oracle's muscle behind it I guess this could change. And the competition is not particularly strong anyway, the smartphone platforms are becoming more fragmented with every major player pushing its own RIA stack and app stores (iPhone, Nokia, Microsoft...) so it's not going to be easy for mobile Flex/AIR, when&if these ship. (Even the massive popularity of Flash didn't impress Apple, so I couldn't see Chet's app in my iPod Touch, hehe.)

  2. RE: similarities... it's almost as if Chet had a hand in both platforms ;-) Very interesting blog post btw

  3. Hey Dean,
    For what it's worth, MXML is actually pretty nice as a declarative format. The tag-property/value approach of MXML maps nicely onto the underlying objects, so that it's clear what's going on. It's not really another language, but rather a declarative way of dealing with the objects lying in ActionScript code underneath.
    This 1-1 mapping also makes it easy and powerful to tool. So, for example, the DesignView in the Flex IDE can switch between code and graphical view, and you can edit in either one because it's easy for the tool to parse code changes you've made in MXML because the declarative syntax is so straightforward. Doing the same in a procedural language would be much tougher (witness Matisse for Swing and the read-only code that it generaties).

    As far as the operations and code looking similar, well ... there's only so many ways to describe a 2D transformation, so I'd expect the code to look pretty similar in any platform that did something similar...


  4. Very similar, Flex demo does not show and Java demo just shows spinning logo. Perhaps one day rich clients will actually work across the board. :)

  5. "but Flash is still everywhere and it just works" I love it when people say this. It isn't true. And when it is broke, it is really broke. With Java at least i can get logs and stack traces.

    For instance, I cannot view the Weather Channel radar on one pc in FireFox. Can't fix it. Soooo i just open tab in IE.

  6. As for Deployment - JavaFX also works (will work shortly) on TVs (see this year's JavaOne)

  7. I don't see XML as any advantage over a procedural language with sane syntax, like Java, JavaFX or most modern languages (i.e. unlike the mess of C/C++). Matisse may be less than perfect in this area, but I was using Borland's Delphi 1.0 back in 1996 and it did a pretty good job in "two-way" editing... if 13 years old technology could do that, we can surely do it now with current OOPLs.

    Of course, XML makes your parser work very easy, it's great for cheap utilities that I can write over a weekend. But in a professional IDE or design tool I'd expect that handling the full grammar of JavaFX Script (or similar languages) shouldn't be a major part of the effort. And it's great to not be forced to split your form in different files with completely different syntax, as even Flex needs a procedural language like AS3 for event handling and program logic. Or even worse, stuffing that code in the XML with CDATA blocks, which is positively the most ugly and aberrant thing ever - CDATA is alone 50% of my reasons for hating the entire XML technology ;-) With JavaFX I can choose to keep visual content and events / logic in separate files or classes, but that's my choice and I can do that separation as I like. (Of course, with a visual tool I'll be at the mercy of the tool's intelligence and flexibility to allow such choices; still, much better than XML where this flexibility doesn't exist even in thesis.)

  8. The JavaFX applet works great in my machine, with JRE 1.6.0_16. No problems to run, and no flicker while scrolling the browser (Chrome) window.

    I find the JavaFX Script language much better than MXML or XAML. For me, JavaFX is clearly the most technically compelling choice, and I am just waiting for JavaFX 1.3 and better IDEA support to start using it.

    On the other hand, I don't think such RIA tools will ever be widely used for the development of typical business web applications. Time will tell.

  9. Chet,

    I appreciate your point about XML making the tooling easier by leveraging existing parser and validation code. But as a format for structuring and writing declarative code, we're going to have to agree to disagree. Given the still fairly wretched state of visual design tools in general, I prefer to write the code. I may be in the minority, and I know Ben doesn't agree, but what do you expect from the guy who ported MigLayout to JavaFX?

    As far as the similarities, I think they go beyond the "there are only so many ways to do X" argument (although, of course, that's part of it). But believe me when I say that I think it's a good thing. As a working developer, I *treasure* conceptual compatibility between platforms.


  10. Casper, mnuttall,

    I was speaking from personal experience. I've never had a problem with Flash except on platforms where it wasn't supported, of course (iPhone, Linux a few years back).

    I still have random freezes and lock-ups with applets.


  11. Dean,
    I am sure that is your experience. Then you should have said "it just works for me". Cause when it comes to computers, NOTHING just works. LOL.

    As for installing Java vs Flex. Java is easier for me (or seems easier to me), at least in FireFox.

  12. The obvious challenge would be to write a translator that would automatically rewrite Flex to JavaFX equivalent (or vice versa). Then you would truly demonstrate the similarity.

    Having said that I wonder at why we still haven't arrived at a point where all GUI stuff didn't have to be part of the application code, but could be developed separately, leaving the developer to only having to manipulate the objects and a HMI designer to dealing with the presentation side of things.

  13. Hi Dean,

    i am java developer and new in javaFx and Adobe Flex.
    i am thinking to learn any one of these.

    Can you suggest me which is best as per current market boom...?


Please Note: All comments are moderated. That's why you won't see your comment appear right away. If it's not some stupid piece of spam, it will appear soon.

Note: Only a member of this blog may post a comment.