Why I Might Not Want to Use Flex
While waiting for my eclipse to shut down, because the Flex Builder plugin again made it crash, I decided to write a little about my Flex experience.
I’m now on the finish straight of a small-to-medium project which uses Flex as a front-end.
On first sight Flex is smooth and pleasant to work with. You draw a bunch of beautiful components, write three lines of actionscript, and here’s is our nice “advanced hello”. But whenever one gets more into the details, the immaturity of Flex (and ActionScript) is too visible, alas.
First, to start with the more general stuff:
- exception handling. For a Java-guy like me, the exception handling ‘not perfect’. When an Error is caught, all you can know about it is .. the error code. Isn’t this too 1990? Stacktraces you can somehow acquire by calling “trace”, but it requires some configurations.
- event handling. At first, it does not seem troublesome when you see the event handling mechanism. object.addEventListener(stringConstantEventType, handlerMethod). Ok, I don’t really mind the String constant (though I should), but the handler method accepts only an Event as an argument. (And when you write your method to have the wrong argument class it starts to feel strange). This makes it impossible to pass other arguments to the ‘listener’. Yes, you can use fields of the declaring class, but what if two asynchronous notifications happen? Actually, a brief look at the Ovserver (listener) pattern shows the right way to do this. I don’t know why it is so strange.
- multithreading. Here I still don’t get things quite well – I read that Flex is single-threaded, and there is no way of manipulating threads. What a shame – especially if the flash player supports multithreading. In fact Flex maybe supports some kind of multithreading, with which it serves asynchronous requests, but are these mechanisms accessible for the developer? Actually, my recent experience hints towards the hypothesis that Flex has 2 threads – one for UI and one for the alleged asynchronous requests. So only one async request at a time. I might be wrong, of course.
- dynamically typed AS3. Completely no problem with this, but something bothered me. When I referenced an objecet by its interface, the compiler did not know it is an Object, and so I couldn’t call its Object mehtods (toString()). So I need to cast it to Object (or whatever I want). And where did the dynamic typing go..?
- event dispatching. This might well go to the section above, but here I don’t mean the machanisms, but some strange implementation details. I have exactly two examples – the Event.COMPLETE is dispatched by an Image before the Image object has marked itself as completed. And this caused problems. Also, the Click event is not dispatched if MouseDown is.
- now on to some very specific things. Starting with the file upload. Something very basic and regularly needed. Prior to Flex 3.2 (and I’m using 3.1), there is not getBytes, or similar methods for a file. So the only option to send the file is via a Http request (instead of some remoting that I would prefer). But ok – I created a servlet which would parse the request, check the size, type, dimensions of the image, and return whether it is allowed to be uploaded or not. But much to my surprise, as far as I understand (please, anyone correct me if I’m wrong), there was no way of getting feedback from the server. So I had to think of a way. I thought of a solution, which I’m ashamed of – I used the HttpStatusError, and I mapped an arbitrary Http status code to a certain error (type not supported, size too big, etc.)
- fonts cannot be loading dynamically – they must be precompiled. Which is my case made me write an java image creation servlet, but I suppose that in the common case it would be sufficient.
- hibernate support – I only took a glimpse of the examples of a hibernate support, saw some re-definitions of collection mappings (<one-to-many ..), and ran away screaming.
So, from these points I dare to conclude that Flex is still immature. Version 5 might be really good. But not now, and not until some serious considerations and rafactoring.
That’s why I’m likely to propose GWT as a RIA solution for forthcoming projects.
While waiting for my eclipse to shut down, because the Flex Builder plugin again made it crash, I decided to write a little about my Flex experience.
I’m now on the finish straight of a small-to-medium project which uses Flex as a front-end.
On first sight Flex is smooth and pleasant to work with. You draw a bunch of beautiful components, write three lines of actionscript, and here’s is our nice “advanced hello”. But whenever one gets more into the details, the immaturity of Flex (and ActionScript) is too visible, alas.
First, to start with the more general stuff:
- exception handling. For a Java-guy like me, the exception handling ‘not perfect’. When an Error is caught, all you can know about it is .. the error code. Isn’t this too 1990? Stacktraces you can somehow acquire by calling “trace”, but it requires some configurations.
- event handling. At first, it does not seem troublesome when you see the event handling mechanism. object.addEventListener(stringConstantEventType, handlerMethod). Ok, I don’t really mind the String constant (though I should), but the handler method accepts only an Event as an argument. (And when you write your method to have the wrong argument class it starts to feel strange). This makes it impossible to pass other arguments to the ‘listener’. Yes, you can use fields of the declaring class, but what if two asynchronous notifications happen? Actually, a brief look at the Ovserver (listener) pattern shows the right way to do this. I don’t know why it is so strange.
- multithreading. Here I still don’t get things quite well – I read that Flex is single-threaded, and there is no way of manipulating threads. What a shame – especially if the flash player supports multithreading. In fact Flex maybe supports some kind of multithreading, with which it serves asynchronous requests, but are these mechanisms accessible for the developer? Actually, my recent experience hints towards the hypothesis that Flex has 2 threads – one for UI and one for the alleged asynchronous requests. So only one async request at a time. I might be wrong, of course.
- dynamically typed AS3. Completely no problem with this, but something bothered me. When I referenced an objecet by its interface, the compiler did not know it is an Object, and so I couldn’t call its Object mehtods (toString()). So I need to cast it to Object (or whatever I want). And where did the dynamic typing go..?
- event dispatching. This might well go to the section above, but here I don’t mean the machanisms, but some strange implementation details. I have exactly two examples – the Event.COMPLETE is dispatched by an Image before the Image object has marked itself as completed. And this caused problems. Also, the Click event is not dispatched if MouseDown is.
- now on to some very specific things. Starting with the file upload. Something very basic and regularly needed. Prior to Flex 3.2 (and I’m using 3.1), there is not getBytes, or similar methods for a file. So the only option to send the file is via a Http request (instead of some remoting that I would prefer). But ok – I created a servlet which would parse the request, check the size, type, dimensions of the image, and return whether it is allowed to be uploaded or not. But much to my surprise, as far as I understand (please, anyone correct me if I’m wrong), there was no way of getting feedback from the server. So I had to think of a way. I thought of a solution, which I’m ashamed of – I used the HttpStatusError, and I mapped an arbitrary Http status code to a certain error (type not supported, size too big, etc.)
- fonts cannot be loading dynamically – they must be precompiled. Which is my case made me write an java image creation servlet, but I suppose that in the common case it would be sufficient.
- hibernate support – I only took a glimpse of the examples of a hibernate support, saw some re-definitions of collection mappings (<one-to-many ..), and ran away screaming.
So, from these points I dare to conclude that Flex is still immature. Version 5 might be really good. But not now, and not until some serious considerations and rafactoring.
That’s why I’m likely to propose GWT as a RIA solution for forthcoming projects.
Hi bozhobg, nice to hear about some actual and real experiences with working with flex.
I myself am working with, and have now for some time been working with, flex, and am starting to feel the pain points of flex too. I guess it will be true for all platforms and frameworks, that there are areas where they are badly designed or lacking in functionality. But some more than others.
For my part, there are two main problems I have with flex.
Number one: The quality of the flex controls. Coming from Java and Suns control of it, we have come to expect real good API design and well thought-out behaviour. This is not what I see in the flex framework.
There are numorous examples. Just this day, I worked with DateField and found that: a) setting dateField.text will set a flag internally in the component, that from hereon prevents it from dispatching certain events, b) setting dateField.data to a String fails, if the format is not the American MM/DD/YYYY as it internally use Date.parse, c) setting dateField.data to a Date instance makes it dispatch a seriously wildly formatted String as a change event (and NOT the string the controls shows) and c) setting dateField.selectedDate does not dispatch a change event of any kind. Crap.
Number Two: And this is far worse. I find the support from Adobe lacking. There are more than one issue in their bug database, that gets absolutely no attention release, after release, after release. In the meantime, Adobe is busy adding now “cool” features in flex3, flex4, … but what about fixing bugs?
Hi there.
Yes, this is exactly what I mean by immaturity – things are not thought about enough. At some points one feels that students were writing code after classes, and here’s our next release (I exagerate a bit, of course).
And, yes, we are used to JDK, to frameworks like Spring, or Hibernate, where, if something goes wrong, we soon find out that the problem is you, not the framework.
And yes – many framework, especially RIA ones, have drawbacks. But GWT, or Echo2 (3) for example have easily curable drawbacks – lack of pretty and functional components – write yourself, or wait till the comunity creates some. Hard styling for Echo2 – Echo3 resolvses it, using CSS, and similar things. While fixing the event handling mechanism, for example, would be very, very hard.
Bohzo, did you ask these questions on the Flexcoders list before you decided it was the framework’s fault?
Event-handling in Flex is all about defining your own custom events and dispatching those. You can pass any information you like to your listeners this way. Have a look at the Cairngorm framework for an example (although you will no doubt be unimpressed with the rampant use of singletons). The same applies to errors – you can subclass Error and use try…catch blocks and event listeners to handle these custom errors in any way you wish. More info on Flex tracing and logging here:
http://techpolesen.blogspot.com/2007/10/flex-trace-and-logging.html
For file uploads, I send an XML string back to the client with a success flag and any validation messages if required. This XML is parsed by a listener to the DataEvent.UPLOAD_COMPLETE_DATA event. Seems pretty straightforward to me.
As far as Hibernate support goes, I think the best open-source solution is dphibernate but it’s a bit immature. Of course, you could shell out for LCDS which has solid Hibernate support.
I actually think the biggest problem with Flex is that people from a Java background come to a new framework in a new language with a new runtime and expect it to be completely familiar and complain when it’s not. AS is not Java, Flex is not Spring and the Flash Player is certainly not the JRE. Are you suggesting that when you first learnt Java, you immediately knew all the answers without having to google a bit or ask on forums?
Hi, as for the data event – I was looking at Flex 3 docs, and saw a bunch of useful methods / events there, but when I tried the “data” or “load()”, they didn’t exist (because they are Flex 3.2), so I started looking at Flex 2 docs which was closes to the methods I have.
I always google things. I know the article you gave about logging. The log file never appeared, alas. Maybe permission problems, I don’t know.
For the event handling – I want to pass certain data with a predefined event – MouseDown for example.
And you may be right about the fact that we do not like Flex (and AS3) because it is not Java. But this is maybe due to the fact that we are used to everything being smooth, predictable and well-designed in Java 🙂
Flash player supports up to 4 async request
To sum up:
Why I might not want to use Flex?
– Because I don’t know how.
To sum up:
Why I might not want to use Flex?
– Because I don’t know how.
It’s interesting to read your issues, but I’m not sure you have the right answer in re-architecting to GWT.
OK, it means you can do all your coding in Java (so lots of points for language familiarity) but I’m not aware that it counts as a mature product.
I’ve seen this pattern happen repeatedly (‘X is rubbish, I’ve read about Y which must be better’ then next thing you know ‘RubyOnRails is rubbish’
Client-side threading will still be an issue as most browser runtimes are more restricted than Flash in that respect.
It is surprising to see no mention of zk from http://www.zkoss.org in a certain segment of RIA developers who want to simplify their development practices.
Part of the reason is that zkoss does not heavily adverties its programming model wherein you can do all the programming in Java using a richlet. Once you get that part of ZK it will be hard for you to web programming within any other framework.
Hi Joker.
Instead of making such irrelevant “summing ups”, why not try to address all these issues. The comment of Darren addressed a few, but finally only 1 (or 2 at most) are actually due to my lack of big experience with Flex.
JulesLT: the idea here is not “I’ve read Y is better”. I’ve used both. True – on small-to-medium projects, but still..
gogo: I’ve only seen ZK samples, and it didn’t grab my attention. Ever since I’ve seen many news of it improving, so it can be a good competitor as well.
As a Java developer, working with Flex for almost an year was like a fresh breath of air. And, as pragprogs say, it was the new language one needs to learn each year.
I must say I sort of made the same mistake of looking at Flex though Java’s eyes, which is fundamentally wrong. Flex/AS3 is different. And as there is a “From Java to Ruby” book, there should also be one as “From Java to ActionScript”. Flex has an history of itself and a different market path and a different business owner backing it up. It’s natural to have its own issues also.
As client side technology, I personally find the MXML+AS3 mix as being extremely powerful. GWT Swing like programming or DHTML will hardly ever by that productive. If Google will ever decide to offer support for Groovy and have a decent markup language, HTML or whatever, then we might see something similar coming.
Flex development may also be painful, but that’s also because most of the time things are pushing us so hard that we don’t find enough time to sit down and learn the technology properly. It happen with myself, it surely happens to others.
As for the problems you have with uploading file, it might be well be a matter of Flash 10 (which comes with Flex 3.2) vs. Flash 9. In Flash 10 they’ve introduced this File System direct access from Flash that allows you to load the file without first uploading it to the server. And, also, you should be able to send back a proper HTTP response to the FileReference.upload HTTP request. Hey, every JavaScript toolkit has upload support that relies on Flash as the best solution! 🙂
Until Java will run into Flash VM, enjoy your Flex adventure! 🙂
Cheers!
I must agree with you. GWT makes for sense for Java developers.
I’m curious about what sort of information you’d like to send with a MouseDown event. You have access to the currentTarget property, so you can easily get state information about the component that dispatched the event. What is the information you need that isn’t available to the listener?
Also, there’s a good article on basic Flex error handling here:
http://marxsoftware.blogspot.com/2008/11/flex-error-handling-simple-example.html
Following up with what Darren just posted, in all my experiences with Flex, any well planned project has run as smooth as can be expected and was actually a joy to use.
I have to ask the question, maybe your frustration comes from a poorly designed application, or a poor execution of the application rather than a poor language/framework?
Keep in mind, Actionscript is not an “immature” language, and MXML just compiles down to the same AS bytecode that your regular AS does. MXML is just a collection of tags that point to AS classes. Nothing fancy there.
It kind of surprises me that you didn’t extend any of the base classes you were working with (ie. Event). That’s a pretty basic practice in most programming languages.
Darren, I had all the information in the MouseDown, but at first I added a Click handler, which wasn’t called much to my surprise
Alex: check the discussion at theserverside.com so see more of AS problems.
And the classes of Flex (mx.*) need some more time to be smooth.
I’m creating a UI client, so I need the UI events, not more – that is, those that are dispatched by the framework itself.
Coming from Java and working with Flex for a year now, I’ve seen some flaws on Flex too, as on Java. API in Flex is not always straight forward, but so far, I’ve had more trouble with some of the Java API that don’t always make sence, or do make sence but are a real pain to use, than with Flex. So “everything being smooth, predictable and well-designed in Java”, doesn’t match my experience.
Event handling isn’t something I was used to coming from Java web struts world. And I had trouble with it, error code without the message, I think it was a bug in one of the version of the framework, we do have the message now.
Your other complain are I think more specific to your usage of Flex so I won’t comment on that.
The thing I had trouble with in Flex is the lack of Advanced Books. You have everything to begin with, but nothing for real complex stuff. There are some (very good) books on ActionScript, but there is a lack of information available on the Flex part. Well that’s my point of view.
1. exception handling. For a Java-guy like me, the exception handling ‘not perfect’. When an Error is caught, all you can know about it is .. the error code. Isn’t this too 1990? Stacktraces you can somehow acquire by calling “trace”, but it requires some configurations.
trace requires no additional configuration. Simply put the trace statement in your code, run in debug mode and watch your eclipse console. Are you using the debugger at all? Because it is pretty powerful and I’ve rarely seen instances where I cant properly debug my code.
2.event handling. At first, it does not seem troublesome when you see the event handling mechanism. object.addEventListener(stringConstantEventType,
Have you looked into creating your own Custom event class? You can pass data if you need to, as an argument, to your listener. http://www.adobe.com/cfusion/communityengine/index.cfm?event=showdetails&productId=2&postId=7323
3. multithreading.
I can agree with you here, however I believe this will change sooner rather than later. Afterall, SilverLight is multi-threaded
4. dynamically typed AS3.
I see this as a very minor issue. Does casting the objects create a performance hit, or is it that you just dont like the extra typing?
5. event dispatching. This might well go to the section above, but here I don’t mean the machanisms, but some strange implementation details. I have exactly two examples – the Event.COMPLETE is dispatched by an Image before the Image object has marked itself as completed. And this caused problems. Also, the Click event is not dispatched if MouseDown is.
Are you certain this behavior is 1. not a bug and 2. not a misunderstanding on your part about how the event flow works? http://livedocs.adobe.com/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=16_Event_handling_172_4.html
6. Starting with the file upload. Something very basic and regularly needed
Im not entirely happy with the lack of remoting support for file uploads, but i do not find it overly difficult to do without it. we simply output the status of the upload as text in our upload proxy and capture that, or XML as Darren suggested.
7. fonts cannot be loading dynamically
To a certain degree I understand why this could be limiting, but hey, at least we arent stuck with user system fonts like we have been in traditional html apps. Im not complaining 😉
8. Hibernate support
I dont see this as the responsibility of the framework. Simply put, we can’t be taxing the Flex framework with code that the majority may never use. This is the same issue I hear in other platforms I work with, people want all these features and functionality and then when its all in there they complain about bloatware. Start an OSS project and develop the Hibernate classes 🙂
FlexCoders is an excellent resource for you to ask your questions, there are some extremely bright people there, many of them from a Java background.
At Adobe MAX (San Fran) there was a session on Adobe AIR performance. Thread support was discussed in there. To summarize what I heard: Adobe is looking at providing thread support to developers, however, they want to balance developer “power” and “ease of use”, while having it fit into their current mechanism.
On the issue of dynamic fonts, there is a “Not an ideal” solution to this problem that I use in many of my as3 projects.
(These steps are off the top of my head, so may need some fiddling)
1) Create a .fla and add the font to the library, setup the linkage so it exports as type flash.text.Font (Name “myFont”) & compile.
2) Load the .swf into your app, once loaded use:
var myFont:Class = loader.contentLoaderInfo.applicationDomain.getDefinition(“myFont”) as Class;
flash.text.Font.registerFont(myFont);
3) The only gotcha with this is that when you setup your style objects you don’t refer to the loaded font as “myFont” you need to refer to it with the Font Name of the loaded font e.g. if you embedded Helvetica you would use something like this:
var title:Object = new Object();
title.fontFamily = “Helvetica”;
title.fontSize = “30px”;
title.color = “#000000”;
but you can work around that by putting the embedded font name and path to the runtime loaded .swf in a config file or something
Cheers,
Chris
Hi bozho, i would suggest you to experiment a bit with cairngorm architecture, which will clear a lot of your doubts about how to do disciplined coding with flex. Also, regarding the complaint about references available, please have a look into flex coders which will help u clear a lot of your doubts (grey areas) which you think are flex design issues.
cheers
I am using both Flex 3 and GWT, and my experience is similar in many ways to bozho’s. Flex will give you a nice UI quickly, but there are a lot of gotchas. At least 2/3 of the responders here didn’t even properly understand the issues with event handling that were brought up before blithely stating: ‘Learn how to use Flex.’ In fact, he knows how to use it and you people aren’t listening. He doesn’t need custom events, AS HE SAID ALREADY (see his post: December 1, 2008 at 6:54 am)
Both have a significant learning curve, but IMHO GWT is significantly further along the maturity curve than Flex, and Google at least trys to fix things. The comment about Adobe not fixing bugs is bang on and not one people seem to want to address (surprise, surprise). This is a significant issue, and bit me right in the rear – have you tried uploading a file in firefox via https? Well, don’t bother, it can’t be done! Adobe blames it on firefox and puts their head in the sand. Read the teeth gnashing and ridiculous claims of Adobe here:
http://bugs.adobe.com/jira/browse/FP-201
Ultimately they threw up their hands and said it couldn’t be fixed, and, although said ‘We understand that this is a serious issue and are committed to resolving it’ suggested that either you:
1) Send the file to your server in a different way
2) Find another form of authentication
Um, ya, right, maybe I’ll just create new authentication standard and get the rest of the world to buy into it. Sigh. And to think they couldn’t be bothered to create a workaround, even calling out to javascript if required (which is already done in several places already). Oh, and just FYI – firefox will allow you to upload files via HTTPS from, oh, any other web framework in existence. So much for not worrying about cross browser issues anymore in the Flex utopia. Yes…I am bitter about this issue.
Today there are several very nice widget galleries available that have come to market recently, including http://code.google.com/p/smartgwt/ so the barrier to easily creating a beautiful looking front end is gone too.
Choose whatever framework you like, but to anyone that says there aren’t issues with Flex and you are misguided or just need to learn more – why don’t you learn how to be something other than useless, cause you sure aren’t helping.
@M, do you have evidence that they are wrong, ie. that this is not a limitation of NPAPI (which obviously Adobe doesn’t control)?
There are workarounds – create your own tokens or use a certificate from a trusted authority. Or use a Javascript workaround if you prefer.
Oh, and don’t you think it makes sense that a MouseDown is not a Click? It could be the start of a drag and drop. Or maybe you’ve created a simple Flash painitng app and the MouseDown is the start of a brush stroke. This is not a limitation of the framework but a misunderstanding of how it works.
No-one is suggesting that Flex doesn’t have issues. Anyone who has used it for any length of time is well aware of them. It’s just that most of the issues raised here seem to be related to unfamiliarity with the framework rather than issues with the framework itself. For exampIe, I haven’t heard of anyone else having issues getting a stacktrace.
Please read just a bit of the bug report itself – as the first comment of that bug report states:
“This is really bad situation. Flex filereference.upload creates its own session, and therefore when using SSL it fails. ”
So yes, its clear that Flex implements upload incorrectly by creating its own session, which it clearly should not do. Its not important with unencrypted traffic, and a showstopper with encrypted traffic.
Why should we each have to develop our own workarounds, as you suggest, when this is an obvious and fundamental problem?
‘No-one is suggesting that Flex doesn’t have issues’
Actually, you are wrong, several of the people posted comments like:
‘please have a look into flex coders which will help u clear a lot of your doubts (grey areas) which you think are flex design issues.’
and
‘I have to ask the question, maybe your frustration comes from a poorly designed application, or a poor execution of the application rather than a poor language/framework?’
and
‘To sum up: Why I might not want to use Flex?
– Because I don’t know how.’
Seriously, just…sigh.
Hello! I just wannted to ask if you ever have any problems with hackers?
My last blog (wordpress) was hacked and I ended up losing
months of hard work due to no data backup. Do you have any solutions to prevent hackers?