Adobe Flex 2.0 - First Impressions

A representative from Adobe came to our company today and gave us a demo of Flex 2.0. What is Flex 2.0? Flex 2.0, in all it's Web 2.0 bandwagon jumping glory, is a way to make programming Flash SWF files programmatical, instead of a mouse driven mechanism. In case you've been living under a rock, Flash is a webrowser plugin that lets the user download precompiled binary programs that up until now were primarily used to play vector graphics movies. Now people have used them for numerous tasks, from rich client interaction to embeded movies. The evolution towards the use for Flash for more complex applications seemed quite painful. The developer needed to know ActionScript, the Flash Professional user interface, and a host of other protocols inside the the UI to link it with external data sources. Flex seeks to alleviate some of this pain for developers.

The Flex language, MXML, is XML based, and seems syntactically very similar to JSP. In fact, I believe Flex 1.0 was just a tag library for use in JSPs. However, unlike JSP, it doesn't compile at runtime, you compile it into the binary SWF file.

The other positive that I got out of the presentation is that you can use the Flex SDK without paying a licensing fee. This should open the door for many developers who want to use Flash for its capabilities as a user interface rather than as a medium for movies. These developers will no longer be hampered either by their extreme dislike for developing using a mouse, or by their lack of funding required for the $700 Flash license.

However, Adobe installed some trap doors. As with Flash, there are tools you can buy from Adobe to build software for Flex. The two products are Flash Builder and Flash Data Services.

Flash Builder is a tool that seems to fill much the same roll as the original Flash software, giving you an IDE where you can build your Flex software. It's based on Eclipse, but the dragging and dropping reminds me of the horrors of working on a Java Swing project under NetBeans. This tool has a licensing fee of $499. That's not all that bad, I could probably live without that.

The other program is Flash Data Services. This allows you to connect to web services, Java, or set up a messaging service similar to JMS. The basic version comes free, but it won't scale at all, if you want the scalable enterprise version it's $20,000 a CPU. Um, ouch. 20K is twice as much as an enterprise level BEA WebLogic.

There are some other, more hidden prices. These prices are vendor lock in, proprietary software, a false sense of platform independence, and a false sense of security.

Flash seeks to get rid of all the standards that the web is based on. Though all the standards like HTML, Forms, Javascript, REST, and web services can be made to interoperate with Flex, Adobe would like to make them all go away. All demos we were shown showed Flex as the soul environment, I didn't see any demoing of interoperation with other services. At least if I go with a Java platform for my enterprise integration there is a good chance all my software will work together.

I'm not a total flaming free software advocate, but I do tend to prefer at least open source. When something is open source, I can see what's going on. How can you trust the software if you don't know what it's doing? I understand their reasoning for not wanting to expose the code for their SDK or the Data Services, but I think that if Sun could work it out then so could Adobe. Sun successfully made the JDK open source without too much forking between the Sun, IBM, and Apple version of the JDK. I feel like Sun has always had more of a community process than Adobe ever has.

The Flash player is ubiquitous on Windows and Mac, but it's alwas two version behind in Linux, and it doesn't even work on BSD. The rep said they weren't planning on changing this any time soon, because the market for Linux just wasn't big enough to financially affect them. That's just kind of an annoyance for me personally, as I'm a *nix user, whether it be Solaris or Linux or BSD. I would be more concerned about whether the Flash Data Services will run on anything other than Windows PC. The rep didn't go into this and I wasn't mindful enough to ask. Being forced to use Windows 2003 as the app server for Flash Data Services would be a big turnoff for me, and I think it would be for a lot of the market, as Linux machines have taken a fairly dominant role in the server market.

The rep seemed very sure of the security in Flex. "When was the last time you heard of an exploit in running wild in CNN due to Flash? Unlike IE, where there are constantly security flaws." While it's true that Flash hasn't had problems with security at this point, we'll see how it holds up once Flex starts being used more extensively. There are always holes, people will start interoperating their Flex with other parts of the web, and bugs will creep in. The only way to avoid it might be to make your entire site Flex based, and that brings us back to vendor lockin.

So would I use Flex? For the average web page, probably not. For a rich client experience, maybe. Comparing Flex to the alternatives, there's Applets, XAML, XUL, Ajax, and I'm sure there's other but that's all I can think of. Applets I'm sick of, XAML no thanks, and XUL only works on one browser. I think Ajax is probably the best bet for avoiding vendor lockin. The problem is that a lot of designers have been whining about needing to build widgets in Ajax that already exist in Flash. They might deserve come credence on those complaints. However, I still feel that the problems with Flex that I pointed out still stand, and I probably won't be using it any of my official projects. Despite this fact, I still plan on giving it a try in the near future.