Is The Flash Platform waiting for a Spring moment?
8th April 2010
Background
I’ve dipped my toe back in the Java world recently, and I’m reminded of some interesting Java history that may be echoed in Flash’s future.
Back in the distant mist of Java’s past, most large Java web projects were built using something called Enterprise JavaBeans. EJB was a complex framework developed by Sun, the developers of Java itself (with some input from IBM). EJB had a number of good things going for it, in particular
- It had respected advocates in Sun and IBM
- It addressed some real and difficult problems
but some developers also thought that the architecture and APIs were too complex.
Then a smart guy called Rod Johnson wrote a book about an idea, and he created a small framework called Spring to illustrate that idea, and the Java world started to change. Now, EJB is no longer the de-facto standard in the Java world. A smaller, lighter, more agile, more flexible framework called Spring has taken over. There are some who still use EJB (and EJB has become smaller and lighter in response to Spring’s success) but Spring is the framework in demand.
What has all this to do with Flash?
Replace Java with Flash, replace Sun with Adobe, and replace EJB with Flex and you might see a parallel in which Flash is ripe for a smaller, lighter, more agile, more flexible framework than Flex.
That shouldn’t be seen as a suggestion that Flex is rubbish – far from it. I use Flex every day and am often amazed at how good it is. Yet just as often I’m annoyed by its faults. Because Flex isn’t perfect, and its imperfections run very deep. All the new stuff in Flex 4 is great (most of it at least), but it keeps getting bigger, more unwieldy, more complicated.
So I suggest that, as with Java and EJB a few years ago, Flash is ready for a newer, lighter framework to evolve to replace Flex. I don’t know what that framework is but I suspect it will have most of the following attributes
- It will start as something simple, with a strong foundation and the potential to grow.
- It will have some very strong developers at its core.
- It will have at least one project member with an ability to market effectively to the developer community.
- It will be open source.
- Its roadmap will develop through open discussion with the community.
- It will have a very active developer community around it.
- It’s probably a project that has already begun.
It may be one project, or it may be a merger of many. Maybe it’s that little project you’ve been working on in your spare time. Whatever it is, I suspect a couple of years from now we’ll have a serious alternative to rival the Flex framework.
There is also a follow-up post looking at some projects that might evolve to replace Flex.
Tags: Flash, Flex, Frameworks

5 Comments add your own
I’m hoping so!
Jacob Wright | 8th April 2010 at 15:12
I’d say that Keith’s Minimal Components tick a fair few of those points.
But is a component set on it’s own enough? What more would you want/need? More layout components, like hBox & vBox maybe?
How about some service abstraction?
Are you looking for another RIA Framework, or one that can also handle “creative experience” microsites?
Does it need a “proper” lifecycle like Flex?
Flex aside, we’ve been through a bit of a Framework obsessed phase, and I’m of the opinion that for the most part it’s been a frustrating time. Is another Framework really the answer, can’t we all just build it, well, how we want?
So long as you’re obeying OOP fundamentals and throwing a few Design Patterns at your code, what harm is there in making your own custom “framework” for each project?
Jolyon | 8th April 2010 at 15:47
Is it still a framework if it’s custom? To me that would imply that there’s something specific about it for that specific application. To me, a framework is something you could re-use for another application that address the same overall type of problem (e.g. Rails + the Active Record pattern).
Allen | 8th April 2010 at 16:43
Hmmmm…sounds a like lot Reflex to me. One challenge with “fixing” Flash/Flex via a lighter framework is that, at its core, it is still the Flash VM, which has a ton of historical artifacts that seem somewhat orthogonal to the needed features of an RIA platform. It always confuses the hell outta me when I hear people with a Flash background talk about “MovieClips” (a very key construct at the Flash level) and how they’re building components on such a creature. Makes no sense to me, but it does to those in the know about the gory details of the VM.
In any case, I agree with your assessment of the need in the abstract. I must admit to being a framework skeptic. Too many frameworks are purpose built for a specific application domain, then when they try to evolve to something more, DLL hell or JAR hell or SWC hell is replaced with framework hell, with incompatible versions or migration challenges, or worse, inter-framework dependencies on other frameworks. Yuck.
But what I can agree with is that the Flex framework has gotten a bit messy, with the bifurcated Flex 4 and pre-Flex-4 component models, a bizarre and seemingly unpredictable component lifecycle and layout model, odd text handling/formatting, all of which perhaps are more related to the Flash VM quirks than we all might realize.
I would also prefer to see Adobe fix some of these issues with the Flash VM (multi-threading being a glaring omission), pulling more stuff from AIR, at the expense of making the Flash VM perhaps a bit bulkier. Perhaps the mobile use cases are the gating factor here.
We plan to look seriously at Reflex, and perhaps participate in the project.
Rick Bulotta | 13th April 2010 at 01:34
Yes, Reflex was one of the projects I had in mind, but not the only one. I just added a link above to the follow-up post that discusses three projects that I think have potential at this time to evolve to replace Flex. There are no-doubt others.
BTW, to me “framework” is not synonymous with Cairngorm, PureMVC and their (MVC) ilk. Flex calls itself a framework, when it’s primarily about component architecture rather than application architecture.
What most frameworks have in common is that they fundamentally influence the way you construct your code. A framework isn’t a tool you use, but an architecture that you extend. It is in this spirit that I use the term in this article.
Richard | 13th April 2010 at 16:39
Leave a Comment comment policy
XHTML: you can use these tags - <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>Subscribe to the comments via RSS Feed