Why Flash Developers Should Care About Flex

Many have questioned the validity of Flex as a platform, and wondered why I like it and use it. I believe for many this is to understand if it is worth investigating, and to shed more light onto where it fits in our future. I will attempt to explain now why I like it, my inferences on where Macromedia see’s Flash & Flex going, and where I see Flash Developer’s within that path.

Why I Like Flex

I like Flex for a number of reasons. What drew me to Flex in the first place was I was bored with Flash. I have reached a point in Flash where I have little to learn in the Flash development world worth learning. I have plenty of things to learn in the programming world, such as additional design patterns, application of them in real world scenarios, and more advanced OOP concepts. There are a plethora of other technologies that would help my career by learning, such as Java and .NET.

A GUI guy by trade, I’m all about the V in MVC (model view controller). Some of my co-workers at work are all about model, and together this makes a good team. Therefore, it is very difficult to find interest in learning additional, model based languages such as Java, .NET, and PHP. While those languages & technologies can do GUI development as well, there is a self-explanatory reason why Flash fits into this equation. So, 8Ball (Flash 8) isn’t out yet, Flex was the next logical step.

Flex’ components are far advanced compared to Flash 7’s. The V2 architecture has been significantly improved upon, there is more fine grained control if you want it, but so much has been easily abstracted that you don’t need to really worry about it.

Flex does a significant amount of busy work that Flash does not. Not only does Flex separate your GUI layout from your code cleanly with the option of merging to various degrees if you need, it also separates the actual design of that GUI. By doing what XUL does best, your JavaScript is the code, the XUL/HTML is your presentation, and the CSS styles your presentation without being merged to it. Same with Flex. Your MXML pages display your form elements, your ActionScript is your code, and the CSS styles your MXML forms. It’s a wonderful separation that is clean, and Flash does not currently do with ease. Not to mention the fact that Flex Builder, the IDE that is basically Dreamweaver with improvements, with which you author MXML pages & code ActionScript, integrates all 3 of these technologies very well. Flash does not.

Now, I don’t really give a flip about the fact that MXML is text based vs. the binary based FLA’s, but for many using source control systems, this is a must and supports diff’ing your code.

Finally, Flex is where the action & improvements are. All the components look better than the Flash 7 ones, their designs have been improved, they work smoother and faster (at least they feel that way), and the coding API is much more matured. A lot of Macromedia employee’s in charge of Flex and not are currently on the list, as are talented coders. The traffic is low, and that sense of “wonder” around a new product is there. You can tell not only does Flex have a future, but Macromedia has a clear vision for it, but they are also taking feedback from the community to help shape it.

Where Flash and Flex is Going

I don’t feel that for Flash at all. They have clearly stated that the next version of Flash will be mainly for designers, and there will still be stuff added for developers, but that is not the focus. The lists are about the same problems that new people have, and while I love meeting new people and helping usher them to a more adept state, I’d like to learn something too. I am not sure of Flash’ future beyond device development, which until devices (phones, PDA’s, etc.) get Flash 7, I’m not interested. You couldn’t pay me enough to code in Flash 4 or 5 ‘esque ActionScript. The introduction of JSFL, while an extremely awesome addition, does more to prove to me that they are leaving Flash in better hands for future development, just like Director Xtra’s; the community. If we need something, with just a few additions to JSFL, and most plug-ins and features can be coded by us. While the concept is fantastic, I would much rather build things using a tool vs. building a tool to build things. I enjoy JSFL & tool development for Flash, but I would much rather spend my time developing those as simple, helpful widgets vs. full blown plug-ins to compensate for a need in the community.

I do believe Flash will be around a lot longer. Just like how Director’s still around today, although, I think Flash will still have a more central role because there are nitty gritty details of development you currently cannot do in Flex as easily. As Nigel pointed out in his article, there will still be a tight coupling of Flash Developer and Flex Developer in teams, but I think that only applies to bigger companies. For smaller ones, it’ll be like usual; the Flash Developer does both the Flex work, plus the production art, plus the Flash work. Same as usual, only instead of Flash being the final authoring tool, it’s Flex.

Yes, I can honestly say that I feel Flex will be used in a normal production environment, my conclusion at the bottom of this article non-withstanding. Although I like to think of myself as a hybrid, I’m really just a Flash Developer, tried and true. That, in itself, showcases a wide array of disciplines brought together under that title, but a lot are more understandings than actual applications. For example, I understand good design, usability, user testing, PSD to PNG conversion and why it’s important in a workflow, video compression, etc. That doesn’t mean however that I actually do interface design, wire frames, user testing, production work (well, I always do this), or video editing. If the need arises, I can, but typically in a multimedia team, I’m the guy that brings everything together, puts it together, and makes it work.

With all of that said, I’ve still done one, clear path: I’ve changed from a designer to a developer. Period. I no longer “design”, I “code”. I’m a developer, not a designer. While most Flash Developers are quick to point out that they can design, and some actually do, I don’t. I’d say that too, only I know that the truth that I hardly ever come close at designing, and probably never will considering my career path. That said, Flash is not the optimal solution for a developer. Flex is close. The mere fact that I am a developer who not only exists using Flash as a development tool, but learned the majority of my development prowess through it (the first 20% in Director), says that I’m a different kind, which leads to a sub-classification: Front-end developer. I would think front-end developers are comfortable with HTML, CSS, Flash, and converting PSD files to usable, optimized graphics. I’d think they’d be comfortable navigating ASP/PHP code mixed in with their HTML, working with designer templates to code the necessary JavaScript, and obviously utilizing Flash for whatever need arises.

Therefore, for a front-end developer, I believe Flex is the optimal solution. Frankly, though, I have a hard time seeing someone only using Flex, whilst another uses only Flash. I’m sure that’s what Nigel meant, but in my opinion, back-end developers should stay the heck out of Flex, and in their respective back-end sandbox, just like I should never touch Java or CF or any of the back-end services. That said, it’s truly an idealistic statement. In the real world, a pragmatic, business orientated one, people wear many hats. Therefore, I could see how I could be coding the Java service via OpenAMF, the Flex, and any necessary Flash. The same holds true for many of the talented people I’m seeing on the lists; ColdFusion and Java gals and guys coding both the back-end and the front-end. Although the waters may appear murky, I think the intention is for front-end developers, but because the barrier of entry is so low, approaching GUI has never been easier for even back-end developers, and a good looking, awesome potential GUI at that.

Another point to add is that history is repeating itself. Director 5 implements Lingo, Flash 5 implements ActionScript. Director 8 implements ground breaking new feature of 3D, Flash 8 implements ground breaking feature of bitmap blitting. Director lives on as a Flash support product. Flash, for developers, will live on as a Flex supporter product. The device gang probably disagrees on that last point, I bet.

So where am I again?

For Flash Developers, I see Flex as another tool to add to the Flash Developer repertoire, only this one has the effect of potentially changing one’s title. Flash Developers in many small companies, will be doing Flash and Flex development in tandem; back-end developers will have little if anything affected on their end. For those things that do change, probably for the better and both sides positive about the changes. Flash Developers will being using Flash and Flex in their daily jobs, and compiling the majority of their actual applications in Flex, whilst their supporting components and sub-movies/smaller applications in Flash. Other companies who were using Flash, for example ColdFusion/Java shops will instead move to Flex as the approachability for those types of back-end developers will be extremely appealing, and the expectations will be more easily met. Flash developers will be contracted out for component development, expected to make custom SWC’s to use within an ongoing Flex application, or for additional Flex coding work.

The same will hold true for bigger companies; again, I have a hard time seeing what Nigel describes as how a Flash developer could NOT know and utilize Flex and a back-end developer could stand to spend half their time in Flex. It just doesn’t click for me. It seems like a gross negligence of responsibility appointment. Instead, I think Flash developers will be replaced with Flex developers, only it’s the same person, and they know Flex and Flash instead of just Flash.

“But Jesse, Flash 8 will still have tools for developers. I mean, we helped bring Flash where it is today.”

Oh really? Devices will be taking another 2 years to mature in player version to where serious developers want them. Why should Macromedia enhance anything currently for that initiative; from what I’ve seen, especially with PocketPC which supports 7 already, Flash does that well already.

David Mendels, EVP and GM at Macromedia, has recently stated on the Flexcoders list in response to a Flash Developer asking if any of the Flex changes to the V2 architecture would make it into 8Ball, or perhaps a DRK, “…Either way, to set expectations, we do not expect any major changes to the components prior to the next major release(s)…”.

The ideal many had of Flash, Central, and Flex all having 1, global SWC file which contained the entire framework (as Flex now currently does) is dashed upon the rocks violently. Many of us were frustrated and wanted the same components for all 3 products. If Macromedia updated 1, all 3 products would get updated, and all 3 would look the same to end users. From a designers’ standpoint, this sucks, but from a developers’, it rocks. Well, it would of…

Without any uncertain terms, your future is not in Flash, only with it and Flex. Abandon all hope your future as a Flash Developer is strictly within Flash, and Flash alone. The RIA revolution is here, and this year promises additional big projects, but Flash will not have all of that pie. If you want the same amount you used to have, and perhaps more, learn Flex. Change your title to include Flex in it. It’s ok if you hardly ever do Flex development, just be darned familiar with the program. I’m sure once you see what it has and Flash does not, you’ll be more inclined to do Flex projects vs. Flash ones anyway, thus keeping your skills up to date.

Again, I don’t think this is another Flash Remoting, or Flashcom… Flex to me is the forerunner, with the most potential for growth and innovation in terms of RIA and application development. It has better components and will still have better components when Flash 8 comes out, and it’s compiler spanks Flash’s in terms of feedback and debugging capabilities. The application allows adjustment of fine grained application details such as script timeout and recursion limits, something one can only do in Flash using ActionScript Viewer, a 3rd party application. To me, Macromedia has clearly shown that most of its resources are aimed at making Flex more kick ass than it already is. If your impressed with Flash Player 8’s improvements, so am I, but Flex gets those too (as does Central, Breeze, etc.).


Without further ado, let me remove all validity from the above, because I can. What confuses me about the above to no end, and brings doubt to most everything I’ve said specifically about Flex’ place in my and your future, is the Flex pricing.

The main reason my company isn’t using Flex right now is pricing. I have no qualms about my ability to convince everyone in my company to switch to Flex vs. Flash as the primarily development, whilst still keeping Flash around because it is without a doubt still necessary.

I don’t, though, why? Because my company knows that our customers cannot justify the cost increase in our software offerings. Increasing our price 6 to 12k for something I could do in Flash is an impossible sell. I love Flex and I know it has a ton of things Flash doesn’t, and will never have. Those things, however, will not allow it to gain a foothold.

My only hope is when Flex’ server licensing model comes out. It certainly made Flashcom an approachable solution for projects vs. XMLSocket. Although XMLSocket is powerful, I’d much rather use Flashcom. I couldn’t, however, until Flashcom server hosting became reasonable, which now it is. My guess is, once Flex does, it may offset barrier of entry resulting from price.

Let’s all hope so. I would much rather love a future where my title of this entry should of been “use” instead of “care”.

14 Replies to “Why Flash Developers Should Care About Flex”

  1. Hi Jesse,

    I completely agree with you that Flash developers have to be aware of and care about Flex. However, I do have a couple of issues with Flex as it currently stands:

    1. It should be client-side, not server-side. Of all the advantages you state in your article, none of them stem from the fact that Flex is server-side.

    Having the server render your presentation makes sense in a stateless client like HTML. It doesn’t in a state-maintaining client like Flash. We dropped Generator a little while back because the Flash client can now do what Generator was necessary for. When placed on the server, Flex basically becomes Generator with MXML.

    What we need is a *client-side* Flex.

    I want to write my MXML in Flex Builder and generate my SWFs on the client.

    What could be funnier than having to spend *server-side* resources to render your presentation layer when that presentation layer is state-maintaining.

    There are a lot of otherwise very smart Java/J2EE people buying into this because they want to think of Flash like JSPs — well, Flash is not JSP!

    No, Flex should be compiled on the client and all the server should be doing is serving out SWFs.

    What advantages, really, does having Flex on the server have? The one I can think of is that it handles SWF caching issues — something that anyone can handle with a few lines of server-side code if need be. For everything else, there’s Flash Remoting.

    I can only hope that we will see Flex components in Flash and get a client-side Flex in the near future!

  2. Hehe, I see you read the ‘no Flex components in Flash’ part.

    One of my discussions about JSP with a Java programmer was a bit enlightening, and made me feel good about ActionScript in MXML. The fact that, from what he said (he’s just one opinion), is that a lot of people would much rather have code than tags do work for them. That being said, I much rather writing my code in MXML vs. having MXML tags do the work, so that’s cool to know there are those out there that feel the same in the Java world.

    …I still haven’t figured out the server-side part. I guess because it runs as a service or whatever atop JRun, and these services have some type of benefit. Not sure, not my area of expertise. I will say, though, server-side or client, the compiler is way cooler than Flash’.

  3. hello,

    i totally agree with aral. Jesse, in your essay you primilary talk about the cool components of flex. i understand, that those components are developed in actionscript2.0, so this is flash. i don’t understand, why i should buy flex with all the other stuff included, if i’m actually just interested in the components, that have nothing to do with flex on first sight. And if i’m interested in flash remoting as well, i can get it seperately.

    So, the central innovation of flex for me, is not the components, but the mxml concept. And there, i agree with aral, that i don’t see the point, why i should let swf’s be generated, knowing, that a flash application can dynamically load everything it needs at runtime.

  4. Hi Jesse,

    The only benefit of Flex running on the server is that it manages SWF caching issues. You can write a simple back-end script to manage this for you when uploading SWFs and/or use a database to keep track of SWF versions. Again, this is only an issue when you have a shell SWF that loads in external SWFs and you only want it to load in a new SWF when it has changed (and otherwise use the cached SWF.)

    Otherwise, there are *no* advantages to having Flex run on the server.

    The disadvantages are:

    * It is incorrectly classified as a ‘server product’ to justify server product pricing

    * Your investment in hardware goes up (‘John, I believe we’ll have to cluster the presentation servers!’ Oh boy!)

    * You are adding an unnecessary server and thus, yet another possible point of failure into your project.

    Yes, MXML is great. Flex builder is wonderful and I love the new components. No, they’re not worth the extra $10K and should be included in Flash and/or a client-side Flex compiler/builder.

    Flex does not belong on the server! :)

  5. Hi Jesse,
    i’m with Aral too. I can’t count the times me and others in the community asked for a real commandline compiler to create swf. Add real runtime libraries to this concept and finally Flash becomes a real development tool. I wonder how much longer we’ll have to wait?


  6. And to add to my comment: Flash will not become obsolete in this concept. It still works as the main editor to create graphical and timeline oriented content.

  7. Hey Sven, the only reason I am imply buying into Flex, even if it’s just the components, is Macromedia will not continue to enhance the Flash ones much, as compared to where the Flex ones are today. And it’s not just the components, but the app development workflow. If you compare to where Flex is right now vs. Flash, you’ll see what I mean. There is much more to Flex than just the components, and b/c I’m still learning, I cannot fully quantify and explain it all, but trust me, it’s not just about the components, it’s about Macromedia’s commitment level, and to me, they are more comitted to the future of Flex than Flash as a development platform, and I would think rightly so. I’m with you and Aral on the MXML; while I like the concept too, I’d much rather have a client-side compiler.

    Bokel, considering the way things seem to be going, I’d say either Flash 9, or never… unless those open source compilers get a move on. The player part, however, in supporting runtime RSL’s seems to be in Macromedia’s court. If your really impatient or bored, I’d say check out MTASC, and see what it would take to finish it.

    Yeah, I agree and hope I didn’t communicate it that way, I don’t think Flash will become obsolete either, but I do think Flex will be the primary tool for actual development and/or final authoring compilation.

    Thanks for your comments everyone, it’s a real help to see what the community’s thoughts are, specially about the server part which confused me as well.

  8. Strong work on the artical. I have to say my biggest ill with Flex is the pricing. Its hard to tell if Flex is just not ready for mass consumption and thats why MM is pricing themselves out of the market or they are really going for ‘enterprise’ (ie really way too dam expensive) level licenses. It could be a bit of both. In either case no matter how many bells and whistles (components) the thing has at this point its just not practical.

  9. Jesse,

    You remember the discussion we had about 4 months ago about the direction of the Flash IDE and I compared it to Visual Studio. If you understand what Aral is pointing out and think back about what I was suggesting you can understand what I was talking about.

    Look at http://xamlon.com/ to get a real world example. It creates XAML which is the longhorn equivalent of MXML. It’s not doing traditional code generation, but markup generation. If you use Visual Studio, you will no that there are levels of Studio. Some that only allow you to do component based dev and higher levels that let you actually create components and have finer control etc. This is the stuff I was talking about. I whole heartedly agree with Aral.

  10. I’ve always agreed that Flex should be on the client, sorry for miscommunicating.

    What I’m curious about is why Macromedia made the decision to make it server-side… maybe to get the JSP gents like Aral pointed out.

  11. Just to clarify.. when you say compile on client, I take it you mean the developer as client not the client who views the app? You would want the developer to compile the swf on his machine then deploy to the server, right? Deloying the swf’s to the server (and thus sending swf’s to the end-client) but keeping the MXML with the developer(s).

  12. Yeah. I haven’t read the actual license, though, to see if your allowed to deploy SWF’s made from Flex to the server, kind of like what I did with Central. If you are legally allowed to do that, then one could just have Flex run locally, compile the SWF’s, and then upload to the site in question. It just seems silly to have to run a webserver, an application server, and a servlet or whatever Flex really is atop that just to compile a SWF.

Comments are closed.