Why should you use Flex and FlexBuilder?

Once or twice a week, I visit the archives of the FlashCoders mailing list to see what folks are talking about. Recently, there’s been a huge thread boiling about using FlexBuilder 2 versus using the Flash IDE. On one hand, like me, some people are super excited about FlexBuilder. I come from a computer science background, and by leveraging Eclipse, Adobe is making me feel more at home. On the other hand, some people could be defined as a developer-designer hybrid. Some of these folks want to understand why the Flex framework and FlexBuilder are so cool to guys like me. Many almost seem angry about the existence of Flex.

First of all, the Flash IDE as it is now isn’t going away. If you can’t understand why Flex and FlexBuilder are so cool, that’s fine. You don’t have to use them. Flash will still be there. The only thing you’ll really be missing is the MXML that Flex uses, but the Flash IDE doesn’t have that anyway, so you won’t lose anything that you already have. In fact, as a developer, you’re probably going to get more coding features. Plus, since the Flex SDK is free, you’ll still be able to use MXML if you really need it. I remember someone mentioned that they didn’t want to buy two different IDEs. The SDK is perfectly usable without FlexBuilder. I’ve already seen some efforts to integrate Flex with programs other than Eclipse.

Some people are saying that RIA and form-based development is possible in the Flash IDE, so why should they use Flex? Yes, you can make everything in Flash that can be done in Flex. It all gets output to SWF, afterall. However, it’s just not as easy. A couple lines of MXML in Flex can replace a classful of event listening and all that jazz. It’s great for results coming from web services because you can bind them without having to write nasty XML parsing code. I haven’t used states much yet, but I’m sure someone can add good reasons why these make form-based development much easier. It seems to me that they help put logic for a single state in one defined place. I know that code can get pretty messy with tons of if-else statements when you have to keep track states in AS2 right now.

The component architecture is also much better than the one in Flash 7 and 8. I know many developers that wrote all their components from scratch just to get better functionality and better skinning. Now, I’m guessing that a lot of people will be more than happy to use the components from the Flex framework. They’re free, they’re powerful, and there’s a ton of documentation. The biggest hurdle will be skinning these components, and it looks there are some tutorials about skinning already.

In the end, it’s up to everyone to decide for themselves if they want to use Flex or not. The best way is to go to Adobe Labs and download the FlexBuilder beta yourself while it’s still free, read through the documentation, and figure out if it fits your needs. Certainly, it isn’t just for RIA developers, but that’s one if its focuses. If anything, it’s a better coding environment with all the features of Eclipse. If you don’t think it will work for you, then that’s cool too.

About Josh Tynjala

Josh Tynjala is a frontend developer, open source contributor, bowler hat enthusiast, and karaoke addict. You might be familiar with his project, Feathers UI, an open source user interface library for Starling Framework that is included in the Adobe Gaming SDK.

Discussion

  1. Kevin Hoyt

    Perhaps it might be useful to understand the genesis of Flex…

    RIA was a term coined by Macromedia circa 2000 as the data capabilities in the Flash Player/ActionScript became robust enough for use on a larger scale; an application scale. With this emergence of capability came the emergence of a type of content creator that understood programming, and that was also artistic/creative. This new hybrid wanted to maximize these new features and demanded more from the Flash authoring environment.

    Over the years, that’s exactly what happened. New screens-centric metaphors saw their way into the product. Eventually more data connectivity was added to include making the existing XML parsing a native part of the Flash Player, web services support and eventually remote object connectivity (a la Flash Remoting). ActionScript got a new face in ActionScript 2 and countless new classes were added to it’s libraries.

    To be sure, this inclusion of the programmer often upset designers who felt ignored.

    In recognition of the evolution that had taken place with the product line, enterprise customers began to take notice of what Flash as a platform could deliver. They would purchase a copy of the Flash authoring tool, invest in some training for a few developers, and set off into the sunrise with fresh ideas of application bliss dancing in their heads.

    Then reality struck as they encountered the countless metaphors that were latent to Flash’s animation-centric past. Timelines, tweens, keyframes, libraries, symbols and so on confounded all but the most adept. Many projects that started out as a new vision were tossed in the circular file never to see the light of day. What enterprise developers and architects needed was a metaphor that was familiar to their style of development.

    A declarative markup (XML schema) that exposed a rich class library of components and utilities, to which business logic could be added through the use of an OO language, and that could be compiled to run on the ubiquitous Flash Player – that’s what was really needed. Welcome, Flex.

    To be sure, it’s not necessarily a binary choice. In fact the two can work very well together. Build a SWC in Flash authoring and deploy it to Flex (and vice versa). Load SWF assets and library symbols created using Flash authoring into Flex for a truly immersive RIA. Use the metaphor that works best for you. Not to over-simplify but…

    If you’re an enterprise developer, then it is likely that you’ll feel right at home in Flex. If you’re a multimedia content creator, then it is likely that the Flash authoring environment will be more accomodating. If you’re one of those lucky few that have gifts in both areas, then you can use both – creating media assets in the Flash authoring world, and layering and compositing that content with data in the Flex world.

    Then as the sun sets on more successful projects for both the enterprise programmer, and the creative professional, the Flash Community grows – and that’s good for all of us.

  2. stacey

    Two biggest bitches about building RIA’s in Flash – a) compile time and b) the component framework is a hard sell for so many reasons. Sure you can use MTASC to speed up the compile time, but the component framework already sets you back time if you need a real custom solution. Oh and team development. Try working on a RIA with a team of developers and split up visual based tasks – have fun the whole sharing the FLA experience.

    Then along comes flex. The component framework is solid and stocked with functionality, and relatively easy to skin, and altho there are a few oddities or annoyances, its *NOTHING* compared to working in Flash. Working with many people on a project in flex is feasible and efficient too and I’d argue more so than Flash. Oh and compile time – I no longer get coffee breaks based on when i set to compile.

    Any flash coder who doesn’t love flexbuilder just for eclipse hasn’t used it enough. I might get shot for saying that. Using the eclipse environment makes you realize what you have been missing out all these years. I cringe at the thought of going back.

    Does that mean Flex is better than Flash or vice versa, or that Flash will become irrelavant now that Flex is more matured? I’d argue no – they each have their place. If a client needed a really interactive and high customized interface, I’d still be leaning towards Flash for the ideal solution, since there is still a learning curve on acquiring that kinda functionality in Flex.

  3. Josh Tynjala

    I’m with you, Stacey.

    Eclipse is so much better for coding than the Flash IDE. With Eclipse, you’ve got a ton of extensions and plugins to add support for more languages and all sorts of other features. Now it’ll be easy to set up complex builds with Ant, connect to source control systems, and do other “real” developer things.

    Flash certainly won’t become irrelevant. The Flex framework is a little heavy, so using it for small projects is overkill. As you said, highly interactive sites will still be better in Flash. Designers certainly won’t be leaving, and that’s half or more of the Flash users out there.