Why you might not want to use Flex

Home

News: Why you might not want to use Flex

  1. Why you might not want to use Flex (48 messages)

    At the time being I am doing a Flex project for my client. A lot of people have been praising Flex for being the answer in the RIA world. In one way and the other, it’s true: Flex is really sexy, because it can bring all of the interactiveness and statefulness from desktop app world to the webapp world. But there is a but. It’s good from user’s point of view. But from developer’s point of view, it’s a different story. You might have to think again whether or not to use Flex for your next project if you are currently considering to use Flex. What I’m saying here doesn’t mean that Flex is not good, but rather I’m saying there is a consideration you might have to think about before you want to use Flex, and there is consequences to get all of that sexiness. Flex is good for a reason, but it’s not for the other reason. Doing almost everything in Flex is quite different compared to regular web development using html, css and javascript (or web 2.0). I’ve even made a presentation about this and shared it with JUG-Indonesia several months ago. For some people there will be some pains they have to go through when entering the Flex world. And for some people these differences might not be acceptable because in one way or the other it can affect the productivity of the developers in the team. Anyway, all in all the reason you might not want to use Flex is: With Flex, you would require extra efforts to do a simple thing. That’s it. That’s the only reason why you might not want to use Flex. Even the simplest task that does not require you a web framework to accomplish it, Flex can introduce you an extra effort to do it. Not to mention also solutions that has been made simpler with web frameworks, is not available in Flex yet. If you can live with those hurdles because you are the code ninja and you’ve got plenty of time to do deal with it, then you might not want to read the rest of this blog entry and bugger off instead. Read the rest at http://joshuajava.wordpress.com/2008/11/23/why-you-might-not-want-to-use-flex/ .

    Threaded Messages (48)

  2. Re: Why you might not want to use Flex[ Go to top ]

    I'm I missing something here? There sure might be good reasons not to use Flex, but the examples as stated in the referenced articles are not that good. For one Flex (or RIA's for that matter) is not about page by page navigation. The first example - coordinating master/detail - is simply done using binding. The File Upload example is a bit outdated with the recent Flash 10 functionality being available.
  3. I agree and I think the OP's article is somewhat subjective and even suggests some inexperience. I've found Flex (combined with Java) a real breeze to work with. In fact there is at least one feature I can mention that I think Java is *missing* (namely inline regular expressions - no backslash/forwardslash escaping hell). OK, so I had to write something on the server to handle file uploads - big deal and I've only ever had to do it once. Personally, I don't think TSS is the right place for this kind of post. All the OP is really doing is asking for some kind of language war.
  4. This is actually not a bad blog post but the teaser here is so poorly written it is bound to discourage some viewers. TSS clearly needs an editor.
  5. Re: Why you might not want to use Flex[ Go to top ]

    Some more reasons you might not want to use Flex: The odds of you producing a UI that is better than what you can do with HTML, CSS, DHTML and AJAX is 1% at best. Sure the 1% isn't scientifically derived but that's my been my experience on the WWW. Using Flex requires your users to have flash installed. Many people block flash to avoid ads. It also places a bandwidth burden on the users since this giant XML file must be downloaded to the client to execute the interface. Not good if you're on dialup. Flex UIs are all different and require the user to learn how to use your site rather than build on their existing knowledge of standard websites.
  6. Misinformation[ Go to top ]

    "since this giant XML file must be downloaded" - this shows that you know nothing about how Flex works. MXML (and ActionScript) is compiled down to a very compact AVM2 bytecode by the developer and it is the small, compiled SWF containing that bytecode that is downloaded to the browse to be executed by the Flash Player plugin.
  7. Agree with Flex UI[ Go to top ]

    Flex UIs are all different and require the user to learn how to use your site rather than build on their existing knowledge of standard websites.
    I completely agree with this. With Flash sites, you'll always have to guess where to click and in which pane is hidden the info. you want to see. They should have standardized this like in HTML, for example, underlining a clickable link. GC.
  8. Flex standardizes Flash UIs[ Go to top ]

    The Flex framework provides a standardized approach for UI development with standard controls, just like HTML, that can be skinned, just as folks do with CSS. The explosion of AJAX has led to a lot of custom UIs that are far less intuitive than Flex provides out of the box (so you can create highly customized, non-standard UIs with both technologies if you really want). A custom UI built with Flash has nothing to do with what Flex provides.
  9. Re: Agree with Flex UI[ Go to top ]

    Flex UIs are all different and require the user to learn how to use your site rather than build on their existing knowledge of standard websites.


    I completely agree with this. With Flash sites, you'll always have to guess where to click and in which pane is hidden the info. you want to see.

    They should have standardized this like in HTML, for example, underlining a clickable link.

    GC.
    If you need to build a web page, then build a web page and don't use Flex. Flex is not a replacement to HTML.
  10. Re: Why you might not want to use Flex[ Go to top ]

    The odds of you producing a UI that is better than what you can do with HTML, CSS, DHTML and AJAX is 1% at best. Sure the 1% isn't scientifically derived but that's my been my experience on the WWW.
    Sure, but it will take me 100 times longer. Intranet applications especially do not need to look sexy, they just need to work. I'd take productivity over sexiness any day.
  11. Re: Why you might not want to use Flex[ Go to top ]

    If your users don't use it, what does it matter how easy it is to code? Seriously, Flex sites are HORRIBLE. I'm always amazed at how bad these sites can be.
  12. I disagree. Couple of points to consider: 1) Do you want to build a UI in a robust SVG method, orbroken, divergent box model based on a document paradigm? Trying to build some application-y layouts in html is well nigh impossible. 2) As to downloads, flash/flex compiles to swf, so it's lighter than html/css. There is no massive xml file to download, the xml is a source file. There can be a substantial swf file to download, but in my experience it's comparable to 3) doing anything complex in html takes a lot of javascript. 4) Flex doesn't prevent/discourage authors from providing usable interfaces. Some devs get what I call "bling dazzled" (e.g. "Wow, check out this cool transition!! The screen spins!!")
  13. One more reason: SEO[ Go to top ]

    There is one more reason why one might not want to use Flex: search engine optimization. Flex is simply not suitable for sites that depend heaviliy on search engine results for traffic. All tricks aside, I have not seen one solid solution that makes SEO workable in Flex. AFAIC it is the one thing left to solve.
  14. Hammer.. nail anyone?[ Go to top ]

    This is a bit like saying that your screw driver is really great and helpful but that it sometimes proves difficult when pounding in nails. Flex (and Flash for that matter) are not replacements for Web Technolopgies. Flex is a presentation tier development language which is optimized for creating thin clients that deploy using the web deployment model. One of the worst mistakes you can make using this technology is to try to create something that *should* be done using HTML and JavaScript. While the rule is certainly not absolute, if you are writing something that has more in common with an application (to me this also usually means that it doesn't correlate well with the back, forward and stop buttons) Flex might be the right choice. If your concept has a page-based metaphor, this is likely not the right choice for you. My 4 cents, Labriola
  15. I'm not sure how this ended up on The Server Side. Hmm...let's get this straight: if you're new to Flex, it doesn't work like HTML frameworks like Struts or Tapestry. I hope this isn't a very startling revelation to anyone. Yes, Flex applications are more complex than typical HTML applications. Flex is also vastly more powerful than HTML. I won't bother going through the items he cited in his blog post, but overall this person doesn't seem very familiar with Flex and it's idioms. He's treating things like he would in HTML, like the value in a combo box. The huge difference in Flex is that items in list components *are other objects*, not simple text values as they are in HTML forms. The whole section on trying to get the selected item seems to miss the point completely. You just say selectedItem = referenceToObjectThatYouWantToBeSelected, you don't normally loop over the values trying to match on a string value. The same holds true for most of the other things he cites. If all you want to do is some very simple thing, yes, the Flex version is probably more complex than the HTML version. But Flex applications of any size are doing far more than formatting a dollar value or validating a string field. The behavior is much more complex, and announcing events, triggering other UI updates, advanced formatting and rendering of List and Grid elements, etc. are the norm. If he's trying to say "for simple application behavior, Flex can be more complex than HTML", I'd agree. That's because people building Flex applications aren't providing simple behavior.
  16. I'm not sure how this ended up on The Server Side. Hmm...let's get this straight: if you're new to Flex, it doesn't work like HTML frameworks like Struts or Tapestry. I hope this isn't a very startling revelation to anyone....
    You are right only on the first - F has nothing common with Struts, but I think that Flex is similar to Tapestry, or any other Component oriented framework out there (Wicket, JSF, Swing), only simpler than HTML backed component frameworks. The closest peer would be SwiXML (scripted swing http://www.swixml.org/ )
  17. Does Flex has to be complex?[ Go to top ]

    If he's trying to say "for simple application behavior, Flex can be more complex than HTML", I'd agree. That's because people building Flex applications aren't providing simple behavior.
    So are you saying to accomplish complex problems, you need a complex tool? Geez. That is one reason why people won't adopt Flex then. Thanks for pointing this out.
  18. Re: Does Flex has to be complex?[ Go to top ]

    If he's trying to say "for simple application behavior, Flex can be more complex than HTML", I'd agree. That's because people building Flex applications aren't providing simple behavior.


    So are you saying to accomplish complex problems, you need a complex tool? Geez.
    That is not what he said. He said it "can" be. Things like Flex, while they might seem complex at first (and only for somethings and I really don't think it is that complex) the complexity does not increase or is at least reasonable flat. "HTML" applications become more complex as they try to do more complex things. What I think he meant to say was that Flex makes complex things simple.
  19. Flex doesn't enjoy the same strengths as HTML when it comes to text capabilities and could be resource intensive at times (same could be said about AJAX too). But it does ease the pain in traditional web development and is an absolute bliss from a developer perspective.
    I wrote a short post about it "Are you still not feeling the pain" Shailesh Now Test Management is a breeze
  20. Re: Why you might not want to use Flex[ Go to top ]

    i am personally using flex for the last projects and i have to admit the the introduction of the article is quite correct in my opinion; the sequel of the article is instead quite poor: i did not found one single example that is relevant. Even some user comments about lack of orientation to search engines are totally out of scope: of course flex is built for rich interfaces for basically business systems, where the need of SEO is simply null. I personally love the "flex idea" but what i really totally dislike is the total lack of real integration with the server side: ==> not using remoteobjects - passing xml from server to the client is a pain, other than highly inefficient, and an artificial solution to make things work - posting values is even more artificial, simply terrible ==> using remoteobjects - VO must be duplicated just to make languages compatible - blazeds is simply not mature, several limitations & problems are present moreover: - all the major frameworks are stateless oriented, for html pages, while flex would require a more typical "client-server" approach as programming model - using ORM is a real pain (nevertheless some good tentative like dpHibernate) caused by the difficulties to imlement lazyness - the configuration issues for flex to server integration are not trivial - maven stack can be implemented but with huge efforts and with bad side effects on the IDE, debug, ... so, even if i love the idea of the flex+j2ee, nowadays IMHO it is a premature technology for medium-big sized applications
  21. yeah Flex is not for web 1.0[ Go to top ]

    I agree with many but Flex is not simply for web 1.0 (so SEO but google support that). Flex with RubyAMF or BlazeDS with remoteObject can create good RIA apps but you have to make sure you want web 2.0 UI. Also other solution using Javascript framework has it's own pitfalls so does Flex. Flex 4 has really cool (Thermo or new name) feature where designer creates UI and tool will convert that into MXML component. Now developer can bring data and implement business logic and bring life into that UI. Even developer can return that file to designer (converts back from MXML to designer format) to make more UI changes depending on requirement. Silverlight is also not for web 1.0 i.e. page by page navigation so one should not even talk talking in that direction (one who don't understand talk like that) Appcelerator.org is good web 1.0 where you can mix RIA features with minimal learning curve.
  22. Re: Why you might not want to use Flex[ Go to top ]

    - using ORM is a real pain (nevertheless some good tentative like dpHibernate) caused by the difficulties to imlement lazyness
    - the configuration issues for flex to server integration are not trivial
    There is also Pimento Data Services (http://www.spicefactory.org/pimento/) to be released on Sunday. To be honest, I don't know much about dphibernate, but one major difference is that Pimento does NOT build on top of BlazeDS (instead using its own AMF3 layer). Especially if you are using JPA with Spring you might find the configuration quite painless.
  23. Re: Why you might not want to use Flex[ Go to top ]


    - using ORM is a real pain (nevertheless some good tentative like dpHibernate) caused by the difficulties to imlement lazyness

    - the configuration issues for flex to server integration are not trivial

    There is also Pimento Data Services (http://www.spicefactory.org/pimento/) to be released on Sunday. To be honest, I don't know much about dphibernate, but one major difference is that Pimento does NOT build on top of BlazeDS (instead using its own AMF3 layer).

    Especially if you are using JPA with Spring you might find the configuration quite painless.
    thank you, really appreciated !
  24. Your article compare Flex with JSF, Tapestry and other Ajax framework which is not right. I would love have some features from HTML (simple table format) into Flex or GWT or Swing. But you don't get everything in one. You don't need Flex for 1 page application or CMS type where PHP shines big time or ROR. I know combobox sucks and DataGrid formatting and Form validation. I can also add if you want multicolumn form you have to do extra things in Flex. Also file uploading has nothing to do with Flex. (yeah extra function you can copy from manual in seconds)..list goes on.. but Accordian and some layout containers are very nice + Flex 4/ Flash 10 bring so much to RIA not page driven application. If you take HTML or any other framework you have to write Javascript function to validate your form value. If you are using JSF it is tough to built Ajax interactive UI (also it is server base UI generation compare to Flex -client side UI) Even I figure it out in 6 months time that Flex UI has limitation but it open source and many custom componest are available to do that job (little experience with Flex compare to GWT which sucks at UI more than Flex)
  25. I left a comment on the actual blog post, but there's a couple things wrong here... first off, yeah, what everyone else said: Flex is not HTML, so there's no request/respose cycle and things like file uploads are fundamentally different. Validation works differently. It's up to the developer to code around a lot more, but the end result is far more dramatic and usable. The other issue is the fact that his #1 item is blatantly incorrect (selectedItem and selectedIndex are there for just this purpose) and his #2 item is technically correct but missing one option and overstates the problem. Using an inline object renderer with the DataGridColumn doesn't break the sort and allows the sort of nested XML approach he refers to. That said, implementing the sort function is just too easy to complain about. Why wasn't this entitled "Things I Have Learned About Flex" or even "Going From HTML to Flex is Time Consuming"? Trying to warn people off Flex because you're used to Tapestry just doesn't make sense.
  26. The main concern is agility[ Go to top ]

    I left a comment on the actual blog post, but there's a couple things wrong here... first off, yeah, what everyone else said: Flex is not HTML, so there's no request/respose cycle and things like file uploads are fundamentally different. Validation works differently. It's up to the developer to code around a lot more, but the end result is far more dramatic and usable.

    The other issue is the fact that his #1 item is blatantly incorrect (selectedItem and selectedIndex are there for just this purpose) and his #2 item is technically correct but missing one option and overstates the problem. Using an inline object renderer with the DataGridColumn doesn't break the sort and allows the sort of nested XML approach he refers to. That said, implementing the sort function is just too easy to complain about.

    Why wasn't this entitled "Things I Have Learned About Flex" or even "Going From HTML to Flex is Time Consuming"? Trying to warn people off Flex because you're used to Tapestry just doesn't make sense.
    Jared, You are missing my points. My main concern here is agility. I'm not looking for flexibility. Flex can not accommodate me with this. I've written over and over again on my post that the main concern is lines of code. So I think it's fair to compare it with T5 or JSF.
  27. Re: The main concern is agility[ Go to top ]

    I think the post was somewhat disingenuous in its portrayal of the lines of code necessary for a Flex solution versus an HTML solution. Why include the wrapping form code in the Flex example and not in the HTML example? It's not an honest comparison.
  28. Re: The main concern is agility[ Go to top ]

    I think the post was somewhat disingenuous in its portrayal of the lines of code necessary for a Flex solution versus an HTML solution. Why include the wrapping form code in the Flex example and not in the HTML example? It's not an honest comparison.
    Eventhough I put a form code for the HTML example, Flex still forces you to write more lines of code :-))
  29. yeah not honest[ Go to top ]

    I have seen people jump to conclusion like the person who post saying something is wrong with flex. I mean every platform has that problem. Talk about developing Java base application compare to PHP. anyways one can say whatever he wants but reality says something else...
  30. Missing the point, eh?[ Go to top ]

    Josh, your first two complaints were blatantly wrong and overstated the claim that Flex forces you to use more code. That's not missing any point, that's correcting factual errors that led you to use erroneous data to support your premise. So half the foundation for your point is gone, completely. ;) Anyway, so pretending for a moment that the first half of your post wasn't just plain wrong... if I understand you correctly you're not trying to compare functionality, power, capability or integration. Strictly lines of code. So you're saying the bare minimum lines of code required is what matters most? I'm gonna go with "To each their own" on this one. Go with what makes you happiest, but that's not a comparison I could make. For me the decision is made based on integration, experience, flexibility portability and performance. Then again, since I REALLY EFFING HATE writing AJAX apps (because it just doesn't work well for my addled mind, I guess), I'll take Flex any day.
  31. Re: Missing the point, eh?[ Go to top ]

    Josh, your first two complaints were blatantly wrong and overstated the claim that Flex forces you to use more code. That's not missing any point, that's correcting factual errors that led you to use erroneous data to support your premise. So half the foundation for your point is gone, completely. ;)

    Anyway, so pretending for a moment that the first half of your post wasn't just plain wrong... if I understand you correctly you're not trying to compare functionality, power, capability or integration. Strictly lines of code. So you're saying the bare minimum lines of code required is what matters most?

    I'm gonna go with "To each their own" on this one. Go with what makes you happiest, but that's not a comparison I could make. For me the decision is made based on integration, experience, flexibility portability and performance. Then again, since I REALLY EFFING HATE writing AJAX apps (because it just doesn't work well for my addled mind, I guess), I'll take Flex any day.
    Jared, I've said it over and over again on the post that my main concern is agility and I also stated that though Flex would force you to require you to write more code, you'll get flexibility. But I'm not looking for this. And perhaps someone else would be happy with writing more codes. I'm paid on hourly basis, the more I work with writing codes the more bills my client have to pay. And that doesn't satisfy me as a developer letting my client pay higher bills when they shouldn't have to. :-) I guess you didn't read my post thoroughly and got to emotional :-))
  32. Re: Missing the point, eh?[ Go to top ]

    Josh, your first two complaints were blatantly wrong and overstated the claim that Flex forces you to use more code. That's not missing any point, that's correcting factual errors that led you to use erroneous data to support your premise. So half the foundation for your point is gone, completely.
    The first two points are still valid. 1. item == comboBox.selectedItem as you have mentioned is not reliable. Are you using remote objects? The safest way is to iterate it and compare it one-by-one. 2. sort function will be overridden if you change the format of data to be displayed.
  33. Users pay the bills[ Go to top ]

    That pretty much wraps it up for me! In fact those are the people in my experience who want Flex. Basically, apps built with HTML widgets and the request/response model irritate some people with their limitations. They don't use those words but they respond positively to Flex interfaces and say things like "That's more like it!". My personal experience is that higher-level business people are the group most interested in Flex. Whether the look appeals to them or they find it a time-saver, I'm not sure. Maybe it's just a desire for change? I don't know that Flex is the end-all solution but it is an improvement - from the users' point of view, which is all that really matters. From my point of view as an architect, using Flex strongly encourages a layered or component approach, and that encouragement (some may say complusion) is something I value. Again, of course, that makes no difference to my users ...
  34. Personally I think Flex/JavaFX or Silverlight are the future to go. Simply because they utilize the good of the web (the transport part) and leave behind the evil (the browser). The bowser was never intended for application usage, and even with Ajax is still not that usable. Using the web is becoming/has become transparant on the desktop and the new technologies like Flex/JavaFX and Silverlight will replace HTML/Ajax applications in the near future. Why would I want to use a crappy ill equipped browser when I can have a real platform in which I can develop applications? Use HTML/CSS for what it was intended, display static content and simple actions (like google search). When you want to build your business critical information system, do not use the browser anymore. Use a real platform in which you can develop applications. kind regards, Marc
  35. Nah Forget Flex, JavaFX or Silverlight, Use C++ with QT 4 with that you will have the best RIA of all time with great speed and it is compact. You could also use C++ in the server side with closures and type inference, Java cries for that. C++ will rule next, Mark my words fellows.
  36. if that is what you crave, thats fine by me:) But closures :( Iam using anonymous innner classes since I use Java. Thats my variant of a closure
  37. Nah Forget Flex, JavaFX or Silverlight, Use C++ with QT 4 with that you will have the best RIA of all time with great speed and it is compact. You could also use C++ in the server side with closures and type inference, Java cries for that.

    C++ will rule next, Mark my words fellows.
    Interesting. Qt never came to my mind. Do you know any live application on the net that uses Qt?
  38. Nah Forget Flex, JavaFX or Silverlight, Use C++ with QT 4 with that you will have the best RIA of all time with great speed and it is compact.
    Perhaps someone will port QT to run inside Flash Player with Alchemy. That would be cool. -James www.jamesward.com
  39. yeah I was right[ Go to top ]

    You are from C++ world no wonder you love Python & OOP. I still remember when Java came on center stage C++ people never except it. I mean it happens time and time something new come and people bash them or don't except because of so many reasons. But one who keeps broad profile survive in tough economy. just opinion
  40. If you're creating a true RIA, one in which 95% or more of the code is client side, I really don't see a good argument presented against Flex. JSF, Tapestry Wicket, etc. might come with some small offerings of canned AJAX components, but they are difficult to customize and work into a true RIA. I think a better comparison would be between JavaScript / HTML / CSS times the number of browsers / platforms you want to support vs Flex. How do you set the current checkbox state using JavaScript vs Flex? How does ActionScript 3 compare to the 5 different implementations of JavaScript? Compare client side frameworks with client side frameworks. Are developers more productive trying to comprehend hacky OO paradigms in JavaScript, JavaScript this scoping, and browser quirks, or are they more productive with strong typing, traditional OO paradigms, and a single UI foundation found in ActionScript 3 / Flex? The point about setting the selected comboBox item via the label is correct, selectedItem expects the exact same Object in the bound dataProvider. But you can just extend comboBox and add a setSelectedIndexByLabel(label:String) and tuck the helper code away in your own comboBox class. You face the exact same issues with JavaScript. Flex is more work than pseudo RIA JSF app. But Flex is a fraction of the work of for a true RIA when pitted against JavaScript / HTML.
  41. yeah true[ Go to top ]

    second that very true
  42. Re: yeah true[ Go to top ]

    Flex is easier than JSF
  43. Flex is easiest in RIA framework[ Go to top ]

    JSF or JavaFX or Java in short is complex period. Just learn Ruby basic in 4-5 days and so far like it. ROR should be another alternative with rubyAMF to communicate with ROR. Even BlazeDS and POJO with Flex is so easy..
  44. Re: Flex is easiest in RIA framework[ Go to top ]

    Hahahah a Ruby Zealot. Nah why not better use Python with AMF also is pretty easy and cool or better PHP with Zend framework I hear they have backed and supported by Adobe a module for AMF. Python and PHP are also easy to use and fun but the serious people are not interested in scripting languages that is why the use Java in the enterprise. Let me tell you a secret, Ruby is a joke, they washed your mind (yeah those rails folks) and now they are laughing at you really. This is called a FAD, period.
  45. yeah I bet your like PHP & Python more[ Go to top ]

    I know PHP & CMS (Xoops/Drupal) but hate to write or put HTML or SQL in code in PHP. I hate scripting languages and reasons are enough companies like Object Oriented. But again someone will jump on this to argue differently in PHP favor. Anyways I will come to know in 3-4 days if ROR is fashion, just gimmicks or whatever!!!
  46. Extra Efforts[ Go to top ]

    you would require extra efforts to do a simple thing. Sounds like JSF.
  47. Agility is what, now?[ Go to top ]

    There is a lot more to being agile than writing the fewest lines of code possible. Agility speaks to the ability to respond in a changing environment. How agile will you be when your customer asks you to build some rich charting components or deploy the application you've been building to the desktop? Flex was not designed to be a RAD tool for simple CRUD web applications, although a proficient Flex developer can bang those out pretty damn fast. Flex can allow you to build some pretty amazing applications that simply aren't possible in the browser alone. Shameless plug: http://cynergytv.com
  48. very cool apps[ Go to top ]

    wow Navtrak truly web 2.0 apps in Flex..not seen others yet
  49. What's really important[ Go to top ]

    Sure, there are a lot of good and bad things to be said about Flex, We can al see advantages and for the disavantages, I'm sure solutions exist or will be available in the near future. Point is, being 'relative' new technology equals 'RISK' and all risk should be avoided as much as possible, unless you decide after careful consideration the risk is acceptable for you or your client.