With so many users and bloggers loving flex, I thought I'd balance the coverage a bit. I list here my personal opinions, if you think otherwise that is fine, just don't try to convince me I am wrong. Many people have tried and so far I have not budged, it has rather confirmed my hatred for flex. The thoughts and opinions listed here are my own, and only mine. If you think I represent anyone else but myself here don't continue reading.
So what is so bad with flex then?
If it was just a single thing it would be okay, but it just adds up.
Flex is awfully slow. I know what disillusioned flax fans now say.. "Yes, Flex 1.5 is Actionscript 2 and it is slow, but Flex 2, 3 and air is Actionscript 3 and it is faster". True it is faster but still not fast. As seen in the graph below where I compare the execution of the same set of instructions between a number of languages, My experience is that Java is between 2 and 10(!) times faster than flex 3! My tests are not complete benchmarks but they give a good indication of the crawling speed of flex.Java is not one of the fastest languages around, and it wins this benchmark hands down. Speed is not everything but it all ads up in the end.In all these charts shorter bars are better.
I find that the smallest file size you can get out of a flex application is very big. You can not get it under 100k in my experience. Adding styling and other "features" makes it larger again. In my experience Flex 2 generates larger files than Flex 1.5. I wrote a little Java program just showing a label in a window. Nothing else, it ended up being 588 bytes compiled. The same with flex ended up being 130 548 for Flex 1.5 and 152 332 bytes for Flex 2. Considerably larger.
The official documentation for flex is a joke.Not only is it of very poor quality, but it also fails to inform you of important quirks, features (or whatever you want to call it). Let me give you an example. I was working with a list that had tool tips (datatips in flex lingo), for each of the entries. Well it was supposed to have datatips for each of the entries. I did everything according to the documentation for list, but the tooltips did not show up. I read further in the documentation, nothing. I simplified my function that returned the string to display so it always displayed the same text ("test"). Now it worked! I put the original code back in and it did not work. Something wrong with my code you say, no it was not.. but it took me a while to figure out. I spent quite some time to to through my code trying to see where it was failing, I could not find anything wrong. I then made the function return the same text for every entry but the text returned was one of the list entries. All of a sudden the tooltips were showing, BUT not for the one it should. It turns out that if the text for the tooltip is the same as the list entry no tooltip is shown. This should have been mentioned in the documentation! Simply adding a space to the strings returned by my function solved the problem. Now this is not one isolated instance of documentation being bad. The documentation is really, really bad. In fact when speaking to a senior flash developer I said something like "But it says in live docs it should work like this." (Live docs being the name for the documentation for flex/flash), and he replied "Just because it is in live docs does not mean it is so. I wouldn't trust live docs." This speaks volumes of the quality of the documentation. It is just appalling.
The tools available for flex development is substandard as well. Flex builder 3 is based on Eclipse, while I do not like Eclipse very much it is a good tool for development, my reasons for not liking it is my own. It seems they've taken Eclipse and ripped out all the tools that are not required and left in only the tools they had to. It is buggy, and expensive (I know, you can say that just about everything coming out of Adobe lately).For Flex builder 3 you have to pay AUD 475! This is for software that essentially someone else wrote for Adobe, as they are using the open source Eclipse platform and add just their bits and pieces. I am sure they have a legal right to do what they do, but it just seems wrong to pay so much for a tool that is, lets face it, so crap. I have not used Flex builder 3 for a while now, so I'm starting to forget all the bad things in it, one thing I remember is the fact that there are no refactoring options. Another thing is that it is very difficult to import sources that is in a different structure than the one assumed by FB3. If you for reasons related to version control or otherwise would like to have your source in a different directory, well you'll have to struggle to get that done!
- Platform support
Flex require the flash player, and currently there is no player for 64 bit browsers. This is pretty slack, considering we've had 64 bit operating systems for more than 6 years now, so if you are using a modern PC you can not use Flash (which may be a good thing, really). The solution offered by Adobe is to run a 32 bit browser, which is just annoying as you all of a sudden have to support two sets of dependencies. There is now an alpha version of a 64 bit player for Linux, considering that the production releases are usually pretty bad, I would not touch an alpha release from Adobe with a stick.
I find flash has so far to prove itself to be useful. In my experience there are very, very few cases where flash is a good solution, most of the time it is just an annoying extra. It is mainly used to deliver ads. While I understand the need to have advertising on the web, flash offers very little that can not be done in a different way. I have for the past year blocked all Flash content across all sites I visit, and guess what, the sites load faster, the browser is quicker to respond, and only in very few cases have I had to enable flash to make use of the site (Youtube is of course one of those that require the flash player). Flash most of the time is an annoying distraction that serves little or no purpose.
- Not typed
I know, I know, Flex 2 and 3 are supposed to be stronger typed than Flex 1.5, the operating word here is strongER. It is still not strongly typed. You can still do really strange things and make the code very unmaintainable. I have seen lots of this in my work with Flex. Sure it is "powerful" to be able to create new variables at runtime. But it is actually not very good. Your code will compile fine, and your testing will work fine, but when someone does something you did not expect it breaks. Even Adobe admitted that when they moved the Flex libraries to Actionscript 3 they found code that they wondered how they could have shipped it. The compiler is your friend, and you want the compiler to help you with as much checks as possible. A strongly typed language forces you to write more solid code, because the compler will not let you create a new variable in say a string. Which brings us to my next point.
- Cairngorm forces you to break typing
If you use Cairngorm, and if you use Flex you probably will at some point, you are forced to do weird things. Look at the following code
var call : Object = service.function(params);
call.resultHandler = responder.result;
call.faultHandler = responder.fault;
The call to service.function(params) returns an AsyncToken. The thing is that AsyncToken does not actually define the properties resultHandler, nor faultHandler. So we can not actually make the type of the variable the type we get back, instead we upcast it to an Object assign a new varaiable to it. This is very bad practise, very bad practise indeed, if this came from a school project I could forgive it, but in an official Adobe framework?! No way, this is just sloppy design and an engineering nightmare.
- Easy to do wrong
I believe it was Karsten Lentzsch (author of JGoodies among other things) that said "A good framework makes it easy to do the right thing and hard to do the wrong things". I could be wrong about my sourcing, but the quote holds true anyway. I find that Flex promotes bad design ideas and generally bad design. A look at Caringorm as mentioned above just confirms this fact. Doing things the "right way" with inheritance and other language structures actually becomes hard in Flex. Not impossible but harder than it should be. It is hard to do the right thing so instead Flex users often revert to doing the easy wrong thing, Like adding a variable, at runtime, to a type that does not have that value.
This is a very personal point of course, but I do not like the syntax of Actionscript. I find it annoying I have to type "private var temp:Object" where I think that a simple "private Object temp" would do. This is of course not the only example of the syntax I dislike but there is no point in me spending too much time on all the points of the syntax I dislike. Syntax preference is personal and I do not like the one used in Actionscript.
- Wrong usages
I find that the way Adobe encourages it's users to use flex, and also use it themselves is bad. Following in Adobe's footsteps you end up with HUGE applications that take up the entire browser window. It takes a long time (see the point about it being slow) to do just about anything. You can not close it when you do not need it because the start-up takes too long. Instead you end up with a browser eating huge amounts of ram. Flex can possibly be useful in some cases and those cases are always when it is used as a small part of a website, not the website itself.
- Locks browser
Flash in general is very poorly written from a user perspective. If Flash is busy you can forget using that browser. This is just poor form. Ever heard of threading? One process should not lock the entire browser (not just the window currently open). I find this totally unacceptable in today's world with multicore processors, and operating systems that can handle more than one thread there is no excuse for this stupidity. Respect the user more than lock their browser down. When I was doing most of my Flex development I often ran the Flex application in FireFox and used SeaMonkey for our bug tracker. That way I could use the bug tracker while the Flex application was misbehaving.
- Promotes bad user interface design
Flex, and Flash to some extent, promotes bad user interface design. Flex is all about the "cool" effects, you have animations and effects, but if you are doing something serious this just gets in the way. The first time it is cool after that it is no longer so cool, and starts getting annoying. I want a clean good looking user interface where each and every animation actually serves a purpose. No more "blur" or "accordion" animations when I click buttons or dialogues appear. It is just bad. I know this is all Flex has to offer so if you remove these things you end up with something that is pointless, which makes, as I have already pointed out, Flex pointless.
- No support for threads
Flex or more accurately flash has no support for you as a programmer to handle threads. This may be seen as a good thing, and generally it is not a problem, but there are a number of times where it is a problem. First is if you have lengthy computation (well, actually any time you want to do something not trivial it will be lengthy because it is so damn slow) you have to do it on the main thread, leading to the problem above with browser locking. Second without proper locking you can not write safe applications as threading exists under the hood for you, called "asynchronous" requests, like waiting for a network response. Since you can not do locking you end up with race conditions, and Flex is plagued by them. Most of the time things will run fine but sometimes the "asynchronous" thread will observe your object in an inconsistent state and make modifications to it. I've had a number of these happen. It seems it is in the Flex libraries you have race conditions. Without proper locking there is nothing you can do.
- Flex is between object oriented and sequential
Flex claims to be object oriented, but it is not really. It is still a highly sequential language. One thing that really strikes me is that you can pass "function objects" or as most of us programmers know them as "function pointers". This is how you get around the problem of not having objects in a sequential languages, but in Flex you still have it. "Oh but it is so powerful" the fans claim, all I say is "no, it only leads to bad design". As you may just as well pass the object around, since we are dealing with pointers here anyway the size of an object passed (not the actual object) is 4 bytes (32 bit system implied), and a function pointer is 4 bytes. Same size, it serves very little purpose, and just makes the code hard to maintain.
- Silent failing
Flex and flash fails silently, in most languages you get either a stack trace or the dreaded "seg fault". Flex fails without saying anything, making it very hard to find the unhanded error. In Flex 2 and 3 this has been greatly improved with debug versions of the swf showing a bit more help, but still not enough to make it really helpful.
Security of any flash objects is, hmm, if it was not such a serious matter I'd say laughable. Flash suffer from serious design flaws, Adobe is supposedly trying to fix these but it all boils down to the exporter of the swf setting options that does not seem related to security. Flash suffer from "Security as an afterthought", meaning that security was never considered important until it became essential, but then it is too late to fix it. There are several security holes that are currently available in the flash architecture. Adobe is handling this their usual way, meaning they won't say anything about it, and not fix it for several months. For your own security I'd disable Flash in your browser and only run Flash content from trusted sources, and at that only Flash content you really need to run.
If I get requests for the sources for my tests I can provide them.
So as a last note I can only say that I well and truly think Flex is pointless and as a former colleague of mine said "I wish Flex would crawl into the corner and die", I could not agree more. It brings nothing new to this world, it promotes bad ideals and bad code, none of this is needed.