Flex 2 has been 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 at least heard about this software. Flex 3 has been 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 now. Flex 4 will come to this world next year and while 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 Flex team will find a way to change “could” for “will”.
Flex compiler is slow. During eighteen months between releases of Flex 2 and Flex 3, Adobe was not able to make any serious improvements in this department. 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 eighteen 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) and one Java project. 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 as a 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 IntelliJ IDEA that will support Flex, which should be a good IDE – these folks know how to create IDE’s. But it’s going to be using the same Flex compiler, so I do not expect major performance improvement s 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 the wait for a minute to see the first screen of your application written in Flex. One of the main advantages of RIA is that the users would not need to go through ten roundtrip 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 a shipping info, et al) and there is no need to o these round trips to the server.But the users want to see this only page faster.
Flex 3 somewhat mitigates this problem by allowing creation of applications, which caches Flex framework on the disk of 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 this 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 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 Flex framework. But after the project development is done, some of them will re-write 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 RIA town at this point. In2009, 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.
Yakov Fain