Flex 2 was released in the Summer of 2006 and it was a mini-revolution in the RIA space. Almost nobody knew about Flex 1.5, but now almost everyone has at least heard about this software. Flex 3 was released in early 2008. It has a number of useful new features, but it was not a major release. In my opinion, a more modest 2.5 would suffice. We are expecting more now. Flex 4 will come out to the world next year and while the Flex team has announced a number of very interesting syntax improvements, I’d love to see more fundamental improvements in this great RIA tool.

The roadmap for Flex 4 has the following statement: “Features could include compiler performance.” The word “could” does not sound too promising though. I really hope that the Flex team will find a way to change “could” for “will.”

THe Flex compiler is slow. During the 18 months between the releases of Flex 2 and Flex 3, Adobe was not able to make any serious improvements in this department. The Flex framework is well designed, and one of the most popular words among developers who start using Flex is “cool.”  And it is cool as long as you keep working with small applications. But you’ll start using this word less often if you start working on a real-world project that includes say 50 views.

Add a melancholic Flex Builder IDE on top of a slow compiler, and it becomes irritating at times. During the 18 months between releases of Flex 2 and Flex 3, Adobe was not able to make improvements in this department either. Other than fixing sporadic out-of-memory errors and a new profiler, it’s pretty much the same tool. Besides being slow,  periodically, Flex Builder starts rebuilding  its workspace, which is a process with an uncertain ending.

My current application consists of one Java and about 25 Flex Builder projects (it’s split into separate modules and libraries to avoid creating a large monolithic application). Now you need to be very careful with inter-project dependencies to make sure that Flex Builder will not choke up.

This project ,for whatever reason, started with the Cairngorm  framework that  performed its role perfectly – it acted like crazy glue. With its requirement to register all events and commands in a central location, all  modules are glued together, which defeats the purpose of modules and puts fragile Flex Builder on its knees.

By the end of this year JetBrains will release an IntelliJ IDEA that will support Flex, which should be a good IDE – these folks know how to create IDEs. But it’s going to be using the same Flex compiler, so I don't expect major performance improvements comparing to Flex Builder.

The other serious problem is that Flex generates large bytecode (swf files).  Any mid-size application produces about 1 MB of code that has to arrive to the client before the user will be able to work with the application. Intranet users will not complain because they are sitting on a fast LAN, and loading this megabyte takes about 10 seconds. But Internet users sitting on the low-bandwidth network will have wait for a minute to see the first screen of their application written in Flex. One of the main advantages of RIA is that the users would not need to go through 10 round-trips to the server to purchase an item online. On slow networks, people were abandoning  these sites. Flex applications store the state on the client (your shopping cart, billing, shipping info, etc.) and there is no need to for these round-trips to the server. But the users want to see this only page faster.

Flex 3 somewhat mitigates this problem by allowing the creation of applications, which caches a Flex framework on the disk of a client’s PC. If before your Flex application was a monolithic 1Mb, now it turns into two smaller parts: 500KB of your code plus 500Kb of so-called Flex framework  RSL, which will be downloaded to the client’s PC only for the first time, and if you are lucky, the user may already have these cached frameworks as a result of visiting other Web sites created with Flex. It’s a step in the right direction as long as the user is willing to wait on his 500kbps “broadband.”

There are some tricks that improve the perceived speed of a Web application – an application can display something using a pre-loader while the rest of the application parts are being downloaded. But you still need to download this initially hefty application. Flex produces swf files with only two frames. To see your main application screen (the second frame), all required code has to be loaded (the first frame). Will the end users wait?

Farata Systems has written a utility for Flex Builder 3 called Fx2Ant 3.0 (it’s in Beta now), which uses Adobe’s optimizer and automatically generates optimized Ant scripts for Flex Builder’s projects, reducing the size of produced code. But I want the original swf files to be a lot smaller.

A number of Flash developers embraced Flex and started creating their widgets with the Flex framework. But after the project development is done, some of them will rewrite a large portion of it (again) in Flash, removing the fat Flex framework that turns a 50K Flash widget into a 300K Flex equivalent.

I like Flex - it’s the only game in the RIA town at this point.  In 2009, the situation will change though. Competitors will offer their RIA platforms, and will give Adobe a run for the money, which is beneficial for all of us – every Microsoft needs its Google, if you know what I mean.

• Security Soapbox – Decompile Flash/Flex