Skip to content

Flex2 Opinions

2007 March 28
by Joe

At work we decided to give Flex2 a lengthy, honest trial run as a replacement of the Html/JS used for an important component of our application suite. It is an intranet sort of application where we controlled the environment and it seemed like a promising place to put Flex2 to work.

After months spent learning and becoming accustomed to Flex2 our team decided it simply is not a technology ready for building enterprise applications. We are now taking a pragmatic approach: continuing with Html/JS but using the Flex-Ajax bridge for charting, graphics, and multimedia. In my opinion these are things Flex2 is great for.

To anyone that may be considering the Flex2 platform, know that you will find large crowds of evangelists (many of them Adobe employees) on the web describing trivial applications and simple examples to make Flex2 sounds like a fantastic way to solve problems. When we starting dealing with hard problems our experience was extraordinarily negative.

My biggest issues with Flex2 are the following. My viewpoint here is largely a comparison of Flex2 against Html/JS for building rich internet applications. Though based on months of nontrivial development these are my individual opinions.

  • It is not production ready. It is not a stable product. We have an internal wiki page titled “Flex bugs & gotchas” and its content has grown to a substantial size. Take a look at the latest hotfix notes to see what sort of nontrivial issues are just being addressed.
  • The community is small and inexperienced. Flexcoders and Flexcomponents are great groups if you have trivial questions. We asked a half dozen hard questions over the last few months and those were met with either complete silence or confirmation from a Flex team member that we had bumped into another known bug with no confirmed fix date. Compare this to the mailing list and forums for Spring, Hibernate, JS/Dojo/Prototype/DWR, or PostgreSQL where your questions are answered so thoroughly that you feel questions far more difficult than the ones you face have already been conquered by people more knowledgeable. Patches to specific issues are also the norm in these communities. Maybe patching the Flex2 SDK is an easy process, I didn’t try it.
  • The livedocs are down more than they are up. These would be pretty helpful if they were reliable.
  • Existing examples of reasonably nontrivial Flex2 applications on the web are really buggy. Go visit the Flex2 search appliance or the golf store that someone made (can’t remember the url right now – will look it up) with a debug version of the flash player installed and watch the errors bubble out.
  • The tools are not established. Flex-Ajax bridge is bugged. ExternalInterface is profoundly bugged (see my earlier post about this). The Flex Ant tasks are bugged (only with the most recent update did a failed compile cause a build to fail and most of the command line arguments aren’t stubbed into their corresponding ant tasks). Want to display some HTML in your application? Get ready to wrap your application in an HTML container, invoke an iframe in that container, and then hack massage it into place over your application so that it looks like it belongs there. Granted, all of these tools are still in Adobe labs so it is fair to expect alpha-ish quality, but I need real tools now to build applications with.
  • Adobe’s priorities with this platform are exceedingly frustrating. They are working on Apollo and Flex3 while huge, show-stopping bugs exist in Flex2 and prevent it from being a viable alternative to more established technologies.
  • Flex Data Services might be a good thing. It might even make the platform reasonable for an enterprise-grade application but it costs $20k per CPU. I can buy a beefed out database server with dual procs, 16gb RAM, and a 16 disk sata raid array for less than the price of licensing one of its CPUs.
  • It is extremely difficult to find talent with Flex2 experience or a desire to obtain it. We want full-time, exceptionally intelligent software engineers. Our efforts to find Flex2 developers brought us contractors that refused to work onsite and people that think knowing individual, popular languages is more important that understanding the concepts that make them the same. We work with area recruiters and the vibe from them was much the same.
  • The evangelists drive me nuts. They are too worried about presenting Flex2 as the slickest piece of engineering ever created to discuss the real issues that prevent real work from being done with it.
  • While not unique to Flex2, the compile cycle is killer. I found over time, as our application grew, it completely crushed my productivity. Compare this to pressing F5 with the alternative.
  • FlexBuilder is worth $10 and not $749 (that’s with charting, but if you are using Flex2 you should take advantage of the charting). No refactoring, no find usages, no code generation, plugin problems (we had a hard time getting subclipse and some other plugins to work with it), awfully unimpressive automatic importing, ctrl-space completion, ctrl-click, etc, etc. Comparing the Java intelligence of IntelliJ/Eclipse to FlexBuilder isn’t fair or applicable, but comparing the Html/JS intelligence of those tools to FlexBuilder is and they put FlexBuilder to shame. The design view, though helpful in some situations for coders, is not a design tool. Our designer hated it. The debugger pales in comparison to a Firefox instance with Firebug and the web developer toolbar installed.
  • Flex2 without FDS does not play well with anything other than xml or web services. I can tell by the search terms used to find this blog that people are interested in using DWR with Flex2. We built an Html/JS container that provided a communication layer between Flex2 and our exposed DWR objects and though it worked for basic calls (did not handle timeouts, call batching, or reverse Ajax/Comet) it meant involving a 3rd debugger in development and it was really just very difficult to work with so many layers at the same time. Regardless I will try to post the code in the future to help anyone else in the same boat.
  • The whole platform feels disconnected. If you pull down the source code for the core Flex2 classes and take a peek, you will find big balls of logic commented out. It is as if they starting commenting out things that are broken until it was stable enough to ship. Also the impression I get from working with Flex2 is that Adobe has a grabbag of developers – some quite good, and some quite junior – and then turned them loose on different pieces of the compiler and FlexBuilder. The result is a language that is far less powerful than a fully dynamic language like Javascript and unawareness in some areas of the platform that other areas exist. A concrete example: Flex2 uses metadata internally ([Bindable], [ArrayElementType], etc) and essentially had a wonderfully powerful metadata construct written and working. You couldn’t use this metadata for your own code until 2.0.1 because they hadn’t thought to expose it. Even now you have to build with ANT and use some command line arguments that aren’t stubbed out in the Flex ANT tasks to make it work. Someone smart wrote the metadata code and it wasn’t leveraged in the rest of the platform. That feeling occurs repeatedly.

That said, Flex2 is great for making pretty things involving charting or multimedia. Our frustration began and grew as we tried to complete the nuts and bolts of a large enterprise application with it. If your application is heavy on the areas where Flex2 shines, then it may be worth the frustration. Perhaps your experience has been different? All I know is we are back to Html/JS using DWR for transport and Xulrunner/Firefox for the environment and getting work done again. Apollo sounds promising, but I am more excited about Xulrunner and Firefox3.

My advice is this: If your team has 1 or more of these following trends in place, I would strongly discourage a move to Flex2:

  • You are building an application for the public (you do not control the environment or user base). Flash player 9 is not ubiquitous and the 96% flash player penetration number that the evangelists trumpet include all versions of Flash player. Flash player 9 is no where near 96%. Though it wouldn’t be fair to not mention that MySpace and Youtube are going to help Flash player 9′s penetration number increase faster than version 8′s.
  • You have solid Html/Css/JS knowledge in place now. While I prefer this stack enourmously over Flex2 I also realize there is a learning curve involved. If you have already conquered that learning curve rest easy knowing you are using the superior tool.
  • You are building business applications or applications that aren’t heavy multimedia. Flex2 is great for multimedia and I don’t hesitate to admit its superiority here. Keep in mind that you can use the ExternalInterface or the Flex-Ajax bridge to use Flex2 widgets inside your Html/JS with relative ease.
  • You are building large applications. For smaller applications Flex2 is fine. Cairngorm helps (and in fact may help you keep your sanity) but it doesn’t solve all of the problems.
  • You don’t currently have nightmares about scrollbars and don’t want to start having them :) This will only make sense to someone who has worked with Flex2.

Needless to say, probably the last Flex-related post for this new blog except for the DWR bit or unless I have something interesting to share related to the charts and multimedia strengths we will continue to use. I tried to keep this post objective; it does represent 6 man months of experience. I love many of Adobe’s products and I recognize that there are several cases where Flex2 would be a great tool. Large, enterprise applications is not one of those areas.

That said, it is a new tool in my toolkit and because it has obvious strengths I can certainly see myself using it for those strengths in the future.

19 Responses
  1. March 28, 2007

    Hi Joe (right?),

    Thanks for the honest feedback about your experiences with Flex. We are listening. And if you are willing, I’d love to connect you with Product Management for Flex so that they can get more details behind this feedback. They need to hear it, and want to hear it. Please email me so we can figure out how to best resolve your issues and continue to improve the product. Thanks.

    -James

  2. March 29, 2007

    @James Ward:

    Just to quickly clear something up. I assume by “Hi Joe” you meant to imply that I’d written the article. I had nothing to do with it. I’ve never met Gtuhl, and never communicated with him/her previously (no my knowledge) except by reading this blog post. Thanks.

  3. March 29, 2007

    Almost all the issues you’re talking about are non existent in OpenLaszlo. The builder tool sucks too though, but at least they don’t charge money for it. It is much more stable and with the latest release 4.0 even renders to DHTML as well as Flash. A next release will also support J2ME. The development team is very capable and passionate about making it work for you. Imho there’s absolutely no reason to choose Flex 2 instead of OpenLaszlo.

  4. March 29, 2007

    Joe: I suspect James was able to google up some posts I have made in various project forums under the name gtuhl and undoubtedly I signed some of those posts with my real name. That said, DWR is a fantastic piece of code and I am a big fan of the project and your active involvement in its mailing list and community. My apologies for any confusion.

    James: Though I would be happy to help a project with feedback, I am hesitate to offer much time now that we have changed focus and my hour count is rather high already. Here are some concrete things that would have fundamentally changed our experience with the platform. I realize these aren’t easy things to accomplish and I suspect they are known and queued up.

    - The ExternalInterface bug that causes nested subobjects to overwrite same-named properties of their host objects. Here is the flexcoders post about it. I realize this is probably a Flash Player team issue and not a Flex team issue. The responder in that post suggested this bug is new in Flash Player 9.

    - The IDE needs to have refactoring, find usages, and better intelligence if Adobe is going to charge $749. For comparison IntelliJ costs $499 for the more expensive corporate license and is a far more developed and intelligent piece of software. The fact that Actionscript3 is a strongly typed language and that the IDE is as expensive as it is should allow for some really great intelligence and assistance for developers.

    - FDS should be cheap or free. Some examples of semi-similar bits of software: Hibernate provides fantastic ORM and is free. Mammoth Replicator allows you to build replicated clusters of PostgreSQL databases for $1000 for the first master/slave pair and $250 for each additional slave. FDS costs 20 times that first replicated pair for a single CPU and I would be awfully surprised if the code for FDS is more complex or powerful than Hibernate or Mammoth Replicator. DWR allows well organized, easily maintained communication between Javascript and Java and is free. It may be the biggest parallel to FDS.

    - A real HTML rendering widget would be nice to have. Something like the <browser> tag when building XUL applications that doesn’t require an HTML container to achieve. It is my understanding that Apollo may provide this. We switched directions a couple weeks ago and I haven’t taken a look at it yet because of this.

    - It would be really great if the -keep-as3-metadata mxmlc argument was honored in both run and debug mode of FlexBuilder and stubbed (along with all other missing arguments) into the matching mxmlc ANT task.

    - This issue was frustrating for us. I realize the compiler is probably trying to make the resulting swf as small as possible but it would be great to not need fake lines of code to prevent classes from being optimized away.

    Those are some of the bigger issues that caused some aggravation that I can recall off the top of my head. There are many smaller issues that I can’t express briefly in a way that would make my comment useful to someone attempting to fix them and there are some that are either easier to work around or a matter of personal preference. The latest Flex2 hotfix knocked out a few of these issues – several of them related to data grids. It was a combination of issues like these and a general feeling of inefficiency across our entire development team that lead us away from the platform for end-to-end application development.

    I appreciate you commenting on this post and I appreciate the effort being put into Flex2. Though my post was obviously slanted in one direction, it was based on real, nontrivial experience and in our case we simply had to weigh risks and make a decision. I’d love to see these issues get resolved and as I indicated Flex2 has some real strengths that make it a useful tool in several situations as-is.

    Joe Uhl

  5. March 29, 2007

    Joe Uhl,

    I do read flexcoders and have seen posts by a gtuhl. So I assumed you made those flexcoders posts. I totally understand your time constraints. But I do want to thank you for writing up this information and being honest about the problems you encountered. Many people at Adobe (Product Management, Engineering Management, Marketing, etc) have already read your blog and I will let them know about your further comments. We do take your feedback seriously and will use it to continue building a better product. So thanks again. And I hope to meet you in person sometime. Maybe at JavaOne.

    Joe Walker,

    Sorry for the confusion. I did not assume that gtuhl was you, or anyone for that matter. Since I only knew gtuhl to be a “Joe”.

    -James

  6. March 29, 2007

    Joe,

    I’m curious – what is the HTML/JS toolchain that you are comparing Flex to and how to its pros/cons stack up? AFAIK IntelliJ/Eclipse don’t have a strong design view, or refactoring of JS code, or or or. HTML/JS AJAX development is pretty much roll-your-own and AJAX client-side libraries are a bit of a hodge-podge. As someone with a small team building a Flex2-based application I appreciate the constructive cricitisms but I would like to understand the alternative you recommend. For example you mention “just pressing F5″ but that implies raw Notepad-level HTML/JS development which means way more runtime debugging. My team’s experience seems to be on the while much more positive (and we are not Flex evanegelists, just trying to get a product out).

  7. March 29, 2007

    Hey Bill,

    If your team’s experience thus far is positive there is no reason to switch gears. We persisted for a couple months before deciding to switch back and it wasn’t an easy decision. In our particular situation the Html/JS knowledge is pretty substantial so many of the negatives associated with that approach (a big one being the hodge-podge of libraries and another being a nontrivial learning curve) were a non-issue.

    To specifically summarize tools, I use IntelliJ. It has refactoring and find usages support for Javascript that works quite well if you feed it the information it needs in your project and resource settings. The ctrl-click, ctrl-space, and other similiar shortcuts work great as well. The options are not as numerous as with Java but it is there out of the box. I would have loved a reasonable refactor-rename function in FlexBuilder. The InspectionJS plugin is pretty nice as well for IntelliJ. I read on a blog post awhile back that the Flex team is working on refactoring and find usages in FlexBuilder and when those roll out the IDE will be a large step more advanced than it is now.

    You are certainly correct about the lack of a design view in IntelliJ. Our team didn’t use the Flex design view and our designer did not want to use it either. There were many areas of our code that were too dynamic for the design view in FlexBuilder to render (we just got a big box). It seemed that to make the source code sane and productive for these types of widgets and screens we had to forget about design view.

    As far as specific client-side tools, we use Html, Css, Jsp/Jstl, Javascript, Prototype, Dojo, and DWR. There are certainly roll-your-own aspects to this path but we had the knowledge in house and this list of technologies really play quite nicely together. With Flex2 you are using Mxml, Actionscript, Css, Cairngorm (maybe), and some type of technology for remoting so the number of tools involved isn’t substantially dissimilar.

    With respect to the F5 comment, I speak only for the client-side files. We have our environments situated (really just a symlink) such that changes to jsps, tags, html, js, css, or images are instantly reflected in the deployed application in JBoss. If you need to modify Java or a configuration file you certainly have to do a rebuild and redeploy (but that is server-side logic). If you are working on windows and don’t have symlinks then we have a build target that copies over just the client-side files into an exploded application deployment that concludes in about 2 seconds. When it is time to do a production deployment we have another target that packs everything into an ear and sends it to the desired server.

    Another large factor was we had a lot of existing code written that used DWR for exposing methods and value objects to the client. We did not want to refactor this code into xml or web services and that obviously presented a challenge unique to our project that doesn’t apply to Flex2 in general. We wrote a layer to handle this but the ExternalInterface bug I mentioned really sucked the enthusiam out of that effort.

    We intend to use Flex2 for widgets that Html/JS just isn’t cut out for but in our particular case it made more sense to go with Html/JS for the guts of the application. If someone told me it made more sense for their project to go with Flex2 there wouldn’t be any disbelief or conversion attempt on my end.

    I appreciate the comment, let me know if there anything else I could offer in terms of information.

    Joe

  8. March 29, 2007

    Hi Joe,

    I emailed you before based on your flexcoders posts but will also respond to some of the issues you listed here.

    - The ExternalInterface bug is in the Player and we have it opened to fix in the next major Player release. I am investigating whether we could push that up sooner, though I realize you’ve already moved on and it won’t make a difference for you guys but could for others.

    - Refactoring in the IDE: we have added basic refactoring support in Flex Builder for the next release, codenamed “Moxie.” There will be a public beta in the first half of this year.

    - FDS price: we’re always investigating this sort of thing but I don’t have any new information on it for you.

    - A real HTML rendering widget: yes, Apollo will take care of this and it is something we’d like to add support for in the next major Player release (which would probably be a different approach than how we did Apollo).

    - as3-metadata bug: this is simply a bug, the team has begun investigating and we think there’s a linker error in there somewhere.

    As for adding all the compiler flags into the Ant tasks it’s my understanding that they are already supported. According to the docs the only unsupported options to the mxmlc tag are “version” and “help”. With that said I didn’t try it myself.

    I appreciate you sharing the major issues with us. We’d certainly be interested in hearing about the minor issues as well, putting things together in the context of what affects development teams helps us make decisions about what we do in the future.

    Matt
    Flex PM

  9. March 29, 2007

    Matt,

    Thanks for the comments and follow up. It is encouraging to hear that fixes to the big issues we discovered are in the pipeline. My coworkers made some posts to flexcoders as well – if I get a moment in the next few days I’ll try to communicate any larger issues distinct from my list above. With respect to the ANT Tasks, the last time I pulled down the latest jar from Adobe labs was whenever I made my previous post about Flex2 & ANT. If progress has been made since then I apologize for expressing conclusions based on an old version.

    We may have chosen an alternative platform for this part of our application suite but continue right now using Flex2 for its charting, multimedia, and quick mockups (I neglected to include this other strength previously – the design view is good for this). We write a lot of code and have several interfaces planned for many different audiences in the future so these fixes are still important to us when decisions are made for those. We do have some respectable Flex2 knowledge in house now and several licenses paid for so our team has the ability to match technology per individual application or interface pretty effectively.

    Joe

  10. Paul permalink
    April 2, 2007

    Hi,

    I have just read your comments on Flex 2 and I have to say that I agree with you completely especially the comments regarding the pricing. Both Flex Builder and Flex Data services are “off the planet” demonstrating the complete lack of reality the Adobe management team have regarding the value of their products. I agree Flex Builder is at best a $10 product in its current beta phase. What can you say about $20K for FDS, I can understand the desire to recoup dev costs and generate profit but $20K is rediculous.

    My experience with Flex is that it works, it is not exceptional and if you don’t want to do anything out of the ordinary it will continue to work. It is definitely not a mature product and there is no doubt that OpenLazlo should be considered if you want to stick with a RIA.

    My team have decided to stay with Flex but when we have time will probably port the app across to OpenLazlo in the near future.

  11. April 2, 2007

    Hey Paul,

    Thanks for the input. It sounds like we are on the same page – the pricing is one of the biggest issues with the platform. Maybe I can spend some time in the near future test driving OpenLazlo. I have not written a single line of code in that environment so am not qualified to guess at how it stacks up to Flex2.

    Good luck with your project and team,

    Joe

  12. April 4, 2007

    Hi!
    I have been evaluating a all platforms for RIA development that I can find… for almost one month… each time I fee like “i am going to use X” (where X is Flex, OLaszlo, Echo2, GWT, Ajax4JSF, etc) I find a “but”:
    -But there is no IDE
    -But the IDE is very expensive
    -But there is no documentation
    -But it only works with .NET
    -But it only works with Java
    -But it goes agaisnt standard “XXXX”
    -But there is no debugger

    In Flex case, in my experience:
    -But is not as easy as it seems (as I have learned from this article)
    -But DataServices are expensive
    -But it uses too much RAM

    So, lets go the Laszlo way:
    -But, documentation is very superficial (only simple examples, no architectural guidelines, i havent been able to find something like Cairngorm)
    -But if I use SOAP it SOLO Mode wont work and development/production will consume lots of RAM
    -But there isn’t a standard widely used REST framework in java (JSR-331 too young)
    -But there isn’t and IDE (no debugging, no visual designer, no refactoring)
    -But it is not easy to change form SOAP to REST mode (very different code)
    -But there isn’t a good finished book (http://www.manning.com/klein/ look promising, but it isn’t finished) with an end to end example.

    So… basically, I still don’t know what to do… I guess I’ll find out… and blog about it when I do…

  13. April 4, 2007

    And, well, I dont want to goo the CSS/HTML/JScript way…
    I guess, that as you found Flex unconfortable when compared with the CSS/HTML/JScript way… I find the CSS/HTML/JScript way unconfortable when compared with “SmartClient” way (WindowsForms.NET/Swing)… but the sad part is that building Heavy/Smart Client is not… “in fashion” right now… but I do feel that it would be sooo much easier…

  14. April 4, 2007

    If only swing could make it easier to build stuff like https://aerith.dev.java.net/

  15. Paul permalink
    April 5, 2007

    What this says to me is that it is about time for a technology change. This whole “mashed up” mess we so lovingly call internet techonologes is out of control. Looking at it objectively the whole “java, html, javascript, taglibs, ejb, spring, jsf, ….. Blah, blah, blah” mess is just wrong. On the other side you go the “RIA, flex, openLazlo,…. whatever” and you end up with a half constructed, immature technology that requires a propriatory download. Surely, there has to be a cleaner technology out there that will satisfy the needs of the opensource community that is both single, unifying and extensible.

    Please excuse my rantings …. I haven’t had a coffee yet. :-)

  16. April 5, 2007

    There are a lot of tools out there and no one approach is completely superior to the others so it can be pretty difficult to select a technology and feel 100% comfortable with the decision.

    For now we just have to try and match tools per project based on the differences between them and it doesn’t ever feel easy to objectively do this.

    At least the current situation prevents us from running out of things to learn :)

  17. Antonio permalink
    April 6, 2007

    Hi Joe, hi guys…

    I liked a lot this discussion. I’m looking for a new tool / technology to develop RIA applications too.

    Recently I watched an apresentation of Delphi for PHP, by Code Gear (Borland), and I think it can be a good tool.

    Does anyone had heared about it ? If yes, what do you think ?

    Thanks in advance.

  18. December 8, 2007

    angeles medium psychic medium charlotte psychic

Trackbacks and Pingbacks

  1. Flex Remoting in Ruby? Easy Choice. « Rob’s Blog - Technology, Atlanta, Startups and Stuff

Comments are closed.