Flash Components vs. Flex Components

Been so busy with my current consulting gig up in Detroit, I haven’t had the time to keep hardcore tabs on the community. What I HAVE seen is a good public reaction to the v3 Blaze (Flash 9) components that Grant & Metalliq are working on. Adobe has done well in creating a new market for programmers to create RIA’s via Flex while continuing to enhance its tools for the Flash community. The key point here is 2 communities, aka, 2 markets. It’s getting more blatant every day, but there is still seems to be some unrest regarding why Adobe is creating an entirely new component set for Flash 9 using ActionScript 3 instead of simply just integrating the Flex 2 components.

There are a lot of reasons, the primary being what I just said; 2 markets. To say it another way, 150 – 300k SWF’s don’t fly on public facing, high traffic websites. Many Flash Developers have solved their “should I use Flex for my next project” question by creating a small Flex app, and then seen the resulting SWF file size by using only a few components. “Well, that was easy… *sigh*”.

There is a reason we created our own component set on the current project I’m on, related to the above. The current mx component set has too much extra baggage we don’t need. All the CSS and related styling code is useless. We skin the components via the designs the creatives give us, we don’t setStyle(“color”, 0xFF0000). Those things work wonders in the software development world where design is extremely conservative, the last priority, or not even talked about. Not to mention creatives don’t design with the mx component set in mind.

“A tile list? A box button list? A set of foldable panels interspersed with up-side down ComboBoxes? Um… uh… Flash 8 doesn’t have those, bro… what to do?”

Create ’em. That’s what we did. Instead of the 72k (mx components we would normally use) base set, 12k of that being default component graphics we’d never use, we have a nice 15k. Like Adobe’s plans, ours is made to be lightweight with no-code-needed-skinning the primary engineering goal.

The other reasons would take another blog post. Suffice it to say, the above proves a lot of us still working in the design world cannot utilize the Flex 2 component framework. We CAN still use Flex Builder 2, mind you, to code ActionScript 3; she’s the hotness.

So what to do? Get someone from the Flash community who knows the target demographic, and has previous experience producing a professional set of components for the point of sale. Gee, who do we know that has done that and is qualified? Grant Skinner of mCom, Chafic Kazoun with his phat charting components, Peter Hall with some of his past work as well as working with Aral Balkan on Optimizer, Keith Peters of Bit Components fame, and a few others.

Chafic now has a company and somehow became a fireman (wtf?), Peter is doing his own consulting thang, Aral is doing mad teaching, and Keith is dropping AS3 examples like crazy so I guess he’s contracting. That leaves Grant. I’m sure many other peeps were considered (enFlash, etc.).

Flash Developers don’t need layout engines, CSS, or box models. They need a lightweight, low dependency, and easily skinnable component set for Flash 9. A set that takes advantage of ActionScript 3 speed and bitmap caching, yet eloquently dances around some of the new garbage collector challenges.

Hopefully Grant, Metalliq, and thus Adobe will deliver.

…Even better, hopefully by that time people will stop f’ing paying me to do Flash and instead start paying me to do Flex 2! I’m sure after 6 more months of Flex 2, I’ll just miss Flash again and repeat the endless cycle.

Speaking of grass is greener, some Rabbi in Lucky # Slevin, a gangster movie with Bruce Willis, mentioned how he straddles the fence and thus his entire yard is green. W00t! It was a metaphor spoken in monotone, mind you, but cool nonetheless. That’s why I’ve been promoting using Flex & Flash together, so much so I’ll be uber content when it’s an industry norm.

7 Replies to “Flash Components vs. Flex Components”

  1. Wow! Beautiful. I think you have really gotten to the essence of why Flash vs Flex.

    Looking at the AS3 core classes, we still have to see how infrastructure like remoting gets updated for Flash 9 / AMF3 (for those Flash developers who may care).

    And AS3 promises to be the bomb for Flash developers.

    But ultimately the SWF file sizes are what different Flash from Flex. Flash developers just can’t accept fat SWFs, and Flex developers just couldn’t care.

  2. I’ll be honest and admit i’m not entirely convinced that the two seperate Component sets is a great idea. That being said, I really have not paid too much attention to the whole Blaze thing as my focus now is more so in FLEX then FLASH IDE.


    I’m doing the one thing I thought I would never ever do, drawing a distinction between FLEX and FLASH.

    That’s why i’m not convinced this is going to be a great idea, as can you imagine saying the words ‘Get a Flash Platform Plugin at Adobe and install the FLEX plugin aswell’ – of course not – as they not only don’t exist (seperately) but to even mention that out loud would be a hard thing to digest.

    My concern lies that if you create two distinct markets and say ‘Designers / Web Developers to the Left’ and ‘Developers Designers ‘ to the right? you are splitting the consumer base into portions and the only way to successfully get away with this is to start drawing lines between ‘Lite, Designer, Professional and Enterprise’ – now if Grant & Co (Adobe) can start bringing that position together, then this is a whole new story and I begin to buy into it.

    I’ve been using these stuff pretty much the same time you have Jess and aren’t you yourself getting tired of having to explain year after year what FLASH can and can’t do, what the Adobe ‘eco-system’ has on offer?

    Its like the products are really great and powerful, but there is no ‘Story’ – no roadmap in how the entire ‘Adobe Service Bus’ ties together to complete a picture based on a multitude of contexts?

    Look at the Microsoft or ORACLE suite that is on offer? you only have to scratch a little and you unearth an end to end ‘while its pie in the sky stuff’ story on how it all could tie together.

    Adobe’s is fragmented and disjointed theories made by bloggers and no substantial evidence in plain view on how concepts like Flash 9 will connect to FLEX applications (early days granted) then how they both could connect to Media Server or Adobe Connect (Breeze)????????

    Were’s the path.. show us the path once FLash 9 is released and then we can digest, and gain buy in…

    Maybe Grant let the info out a tad early?

    I’m neutral – just not yet convinced splitting the two code trunks is a good idea.

  3. I’m with scott. I want to believe it’s a good thing but i was hoping for some kind of shared code base where the blaze components branched to allow for us design-y folks to go town in the skinning area. But i do wonder about this seperation and if it will form artificial barriers between the different dev paths. My work bounces all over the place and i like it to be flexible in reuse. Not all of my jobs are throw away code. A lot are but not all, and clients glaze over when you say ‘yes i know it’s built in flash and we’re taking it to flex which is flash as well but the old stuff is not compatible so we need to charge you for the rework.’
    Not to mention how this all fits in to Apollo-can both exist and communicate with each other.

    It’s early though and Adobe is smart so i’ll sit back and wait but i was hoping for some info on interoperability. I do look forward to easier skinning with less bloat.

  4. There are a lot of significant challenges here that Adobe has to surmount. Expecting them to do so in a short timeframe is unrealstic.

    To be clear, Flash does not work well in Enterprise Applications, and Flex, currently, is not reasonably justifiable for agency work. That is a fact. Can you use Flash to make large scale applications pre-Flash Player 9? Sure. Is it better to use Flex? Yes. Adobe knows this, hence supporting those developers. Same goes for supporting the Flash 9 workflow of continous integration with design tools and developer/designer workflows.

    Those are the MAIN use cases that drive their business. Anything else is a want, edge use case, and thus a non-mainline contributor to their bottom line.

    Do I want Photoshop to export PSD’s straight to MXML? Yes. Are there a lot of people like me? No. Thus, Adobe won’t make that a priority because it doesn’t sell more software, nor help develop the market. They need to tailor their products to the main needs of the market in question. Thus, Flash gets priority of Photoshop interoperability. Flex gets priority in supporting traditional developer workflows.

    This hybrid stuff is cool, but niche and doesn’t contribute a significant amount of continued revenue to Adobe’s bottom line. People wonder why places hire unqualified C and Java developers to do Flash projects in the past. I’ll tell you why; because Flash Developers are extremely small in number. Qualified ones. Hence our insanely high rates, and long path of horrid code-bases exacerbated by yearly changes to the way we create Flash / Flex applications.

    To be focused is to succeed, and succeeding starts with clarifying the market. Designers do Flash, Developers do Flex. Those in between are niche use cases, and thus don’t get priority.

    Do they matter? Of course. We wouldn’t be here if they didn’t. Flex wouldn’t have happened had we not utilized scripting in SWF’s to create a revolution.

    Therefore, you can’t please all the people all the time. The lessons are as follows.

    Flex 1 – does a market for Enterprise Applications exist? Yes.

    Flex 1.5 – people want Flex, but the price tag doesn’t work, not everyone uses servers to deploy their apps, Flash Player 8 doesn’t scale, and the open source world wants in as well.

    Flex 2 – designers are better supported than Flex 1.5 with the better live preview, and GUI supported states in Flex builder 2. The open source world has their free framework and compilers. Developers have a great IDE, great tools, and a good application framework. The barrier of entry to RIA’s has been eliminated for programmers.

    Flash 9 – better integration with Photoshop. Components made specifically for the Flash Community since they have different needs than Flex Developers. Easier way to diff animations like you can in Flex as well as being interoperable via the timeline XML.

    The XML is one of the first steps in that process of helping integrate the tools. There will be more, just not overnight.

    I know the above hard facts piss hybrids off, but it’s our own fault for being unique. If there were thousands of us like there are Java developers, we wouldn’t be having this conversation. It’s a business, and Adobe needs to focus on those markets, support them, and create new ones.

    On the flip-side, we aren’t going away. We’ve been here for almost half-a-decade now and we all still get paid. Adobe does recognize the need for interop. If you look at the history that I’ve outlined in this post, you can see that Adobe has recognized community needs, and acted upon them, like Mike Potter has elaborated.

    They know the community at large does not follow into strict Flex / Flash camps, and that the need for interop and supported workflows is large, profitable, and desperately needed.

    They’re working on it, and it’ll happen.

    Regarding fragmentation… dude, this is the multimedia software industry. It’s very nature is pure f’ing chaos. Nature of the beast. Wonder why there is no longer Flash Developer certification? Because there are 50 billion ways to ‘correctly’ code a Flash app. Obviously only about 3 are decent, but how do you certifiy 3 different application development paths?

    You don’t.

    I’m not sure what Adobe can do to clarify the actual PR / marketing perception. I mean, it’s pretty clear to me:

    • design, use Flash
    • create apps, use Flex
    • distributed data, Flex Data Services
    • streaming video, audio applications, use Flash Media Server
    • need a middle-tier, use ColdFusion
    • need a server, use JRun
    • do Production Art, use Fireworks
    • design, the Adobe design product line & CS Suite

    The actual workflow between them? It’s not clear cut ‘database design’ so I think it’s unrealistic to expect Adobe to provide the same for cross product pollination. You bring a lot of subjectivity into engineering workflows when you throw in design, but… that’s what makes it fun!

  5. I agree with a lot of your comments Jess, yet I sometimes wonder are we talking about the ‘AS-IS’ model or the ‘TO-BE’ model?

    Right here, Right now, FLEX and FLASH are different mediums – yet the same output. Why? Not much has been focused in terms of messaging to the Designer market about the existance of FLEX. The Enterprise market aren’t getting as much marketing either.

    Lets put it in realistic terms the FLASH IDE has been around for years, and its THE reason why Macromedia was successful with the rest of the eco-system following suite.

    So from a marketing / contact point it was an easy job to remind people of its existance, there is no ‘new customer’ position its more about stimulating upgrade (with upgrade comes creation, with creation comes new consumer base). I’d argue that the marketing for FLASH would be the web, not Macromedia… FLASH become secondary, a hygiene factor that people would simply associate ‘oh yeah, that’s just FLASH..you can do it with FLASH IDE.. everyone knows that’.

    If you asked most Designers around the world whats great about FLASH 9? They’d probably not give a lot of information over (except the weblogs.macromedia followers).

    In a nutshell I do agree that the FLEX model AS-IS is targeted towards business to business use, rather then business to consumer. Yet, I’d argue that the TO-BE model should not only enable that but also open up to the business-to-consumer model.

    In that best of both worlds. For those designers who need to branch out a bit deeper into the user experience design side of things, by all means give them the MXML approach mixed with Timelines (scarey as it sounds, MXML component vs MovieClip? if executed well in language could have a lot of niceties about it).

    Anywho, my sore point with all this is ‘where are the breadcrumbs between FLASH 9 and FLEX 3.0’ .. where is the roadmap as we have all said time and time again, we need to encourage ‘Designers’ to get involved in the Development space as the segregation is keeping the business concepts stale?

    I’m just after a roadmap to satisify my concerns.. if they were to say ‘today its FLASH 9, to get them hooked on AS3, wait for the market to digest and then release FLEX 3 which will string the two dimensions into one – bringing balance back to the force -‘ then… i would eagerly opt in.

    Right now? the whole ‘Its for designers only’ approach? i’d rather they package it as a Photoshop Addon then a FLASH ‘addon’ :)

  6. A wonderfull read, nice discussion and valid points. The first thought that popped into my mind though was: ‘Hmm, I dont really care. We have with the new flash player everything we need to make anything we want’.

    The new flash player makes it possible for us to use the best of both worlds. When I look at the original discussion about the 2nd component set I have to conclude that I think its a perfect step. At first I was a bit sceptical, 2 different sets of components that are compiled to bytecode that runs in the same player sounds a bit strange. But it actually makes sence, with the Flex component framework they made sure that all needs you could have are present: if you need something that you would only use in 1 of every 10 apps you wrote, its in there. This offcourse pulls its weight in terms of file size.

    In (what I consider) Flash applications you dont need that. If you want something thats not in the components you either tell your boss that its gonna be expensive for the customer or that other development methods are better suited. In Flash applications (again, as I see them) you need some simple forms and a scrollpane. More important though is that you can make em look kick ass!

    It is simply not possible (not in the way that it can not be done, but more in the sence that it would be way too expensive to make) to create a single set of components (flash) that is lightweight and has been extended for ‘extreme’ use (flex). Its alot easier to just create 2 sets. One optimized for performance and magic and the other lightweight, simple and ‘flashy’. It would make me happy to use one set in a banner and the other set in an application.

    Oh, oops, typed way more letters then i was supposed to… Well, thnx for the interesting thoughts, keep it up!

    Greetz Erik

    ps. Sorry for the bad grammar and stuff, english is not my native language.

Comments are closed.