We’re not waiting for Flex 4

Ely Greenfield presented some cool ideas about the future of the Flex framework during his presentation at MAX in Chicago last year. The core idea is that they’re considering drastic changes to really apply an MVC approach to the full component set, which would mean the core components themselves would be viewless controls, allowing you to easily apply custom skins and have complete control over the look of each component. I wrote up more about Ely’s session here. The future of these changes is still unknown, I think we’re all hoping that stuff becomes the Flex 4 framework whenever that gets released.

But the Flex community isn’t waiting. There are a number of people working on similar concepts outside of Adobe. A recent post by P.J. Onori triggered this blog post. I’ve noticed a few others working on very similar ideas, so I just wanted to point this out, and make a note that it’s worth keeping tabs on these guys/projects because there’s going to be some seriously cool shit that’s going to be possible.

  • P.J. Onori released a set of layout managers. These layout managers are very lightweight, are not tied the Flex framework, and in fact aren’t really even tied to the display of the components. They handle different algorithms for laying out objects, ie in a grid, in a circle, etc etc.
  • Stephen Downs (aka Tink) is working on some layout algorithms for use within a ViewStack. The basic idea is very similar, create a set of layout algorithms that determine how the children get placed, but make those algorithms independent of the actual visual component. Tink’s stuff hasn’t been released just yet, but keep an eye out for it soon.
  • Ben Stucki is working on an ambitious project he’s calling OpenFlux to create a complete framework for containers, layout algorithms, and component creation techniques. At a minimal level this will allow you to do similar stuff like P.J. Onori’s layout algorithms. But then Ben is going to be combining his stuff with 3D and we’re going to have flexible 3D containers with complex custom layouts (ie you could build CoverFlow using these base classes in a matter of minutes). Ben is calling the OpenFlux + 3D stuff PlexiGlass. In case you saw the session list for 360 Flex in Atlanta and wondered what the hell Ben’s topic meant 🙂 His session is definitely going to be one to watch at the conference.
  • Degrafa has just been released, which allows you to write complex graphics tags using MXML. A core piece of Ely’s presentation relied on the new mx:Graphics tags that are going to be in Flex 4. The Degrafa team has basically done the same thing, but you can use it now instead of waiting for the next Flex release. What this means is that if you have a set of core components without specific visual designs, you can easily create skins using Degrafa in MXML. This idea of MXML skinning and skin-less base components is crucial to what Thermo is going to allow you to do.

So we’re not quite there yet, but we’re getting close. What I’m seeing is that gradually we’re moving toward a highly-customizable, display-agnostic full component set for Flex, coupled with some advanced display options (using both 2D via Degrafa and 3D via PlexiGlass). What would that let you do? You could define a base data-driven list. Then you could choose to render that list as custom 2D graphics using Degrafa, or you could choose to render it as 3D components using PlexiGlass. The underlying component is the same base list component that has a list of data, selectedIndex, etc. But you could swap the rendering at runtime, letting you toggle between 2D and 3D views, or fluidly switch between different 3D layout algorithms, etc.

Some of the stuff I mentioned is released now, some is coming in the next few months. But keep an eye on these projects, they signal a shift in the Flex framework. I suspect that shift will officially come from within Adobe eventually with a future release of the Flex SDK, but it will come from within the community sooner. It’s gonna be fun 🙂


My writeup of Ely Greenfield’s MAX session

Ely Greenfield’s session at MAX was, in my opinion, the best session of the conference… although I didn’t really attend many sessions at the conference (with so many people walking around who has time to sit in sessions?). But Ely’s was frickin’ awesome. Video recordings of his presentation in Barcelona have been posted by Joao on his blog. If you missed Ely’s session at MAX or you missed MAX entirely, go watch these videos. Seriously, go watch them now. The session was called something like “Flex Roadmap”, which was basically Ely talking about experimental directions they’re going while thinking about Flex 4.

Praising Ely
If you use Flex you know Ely. He’s formerly the charting master on the Flex team. I heard he wrote most of the charting framework with his eyes closed in 3 days. He’s one of the smartest guys I’ve ever met. His blog was an amazing resource while I was learning Flex. If you’ve been dabbling in Flex chances are you’ve seen some example code that he posted on his blog. Maybe you’ve seen this, this, this, this, or this. Turns out he’s been busy and hasn’t been blogging, which I’ve thought was a horrible idea. I think Ely’s blog posts are some of the most inspiring code examples out there, and his blog alone has probably convinced more people of the value of Flex than any other single source (this is all very biased, I learn extremely well from reading good source code). But Ely hasn’t posted a blog entry since March 19. WTF? I’ve often wanted to write a letter to Adobe on behalf of the Flex community and say “I don’t know what you have Ely working on, but give him some time to blog cool shit again. Whatever he’s doing can’t possibly help Flex more than his blog.”

Ely’s session at MAX was the first time I got a look at what he’s been doing, and it was the first time I thought to myself, “Oh, THAT’S what he’s doing? OK, you win. Keep him doing that.”

Creative Thinking from a Blank Slate
I want to try to get to why I thought this session was so good. To get a little perspective: we’ve got the Flex framework, which is something close to 300,000 lines of Actionscript code. That’s a big code base. That includes some monster classes like ListBase and DataGrid. So with that in mind, Ely gets up there and basically says: Let’s start over and really think about these components. Boil them down to the core functionality. What IS a list? Who cares that we have this ListBase class of over 7,000 lines of code. Maybe it’s not right. Let’s make it the right way. Let’s really figure out what the core functionality of a list is (and it doesn’t involve laying out scrollbars or clipping content or laying out items vertically or horizontally). He goes over a dramatically different way of creating a core list component in the session (see the last couple video segments).

There’s a really important (and dangerous) thing happening here. Most people would look at the current state of Flex, which includes a proven, stable, large code base and they would take that as a given. What I mean by that is that most people would think about how to take the framework and tweak it slightly to make it better (kind of like the improvements from Flex 2 to Flex 3). It takes balls (and brains) to be able to look at such a code base and say “Let’s rethink this. Knowing what we have learned from the past few years of Flex’s life, is this the right way to make a framework?”

That’s a leap that I think is more difficult than it sounds, and it’s something that I think is important for all software development. Too often we can start taking existing ways of doing things as the only way of doing things. Say you’ve been working on a project for months (or years) and the product now does a bazillion more things than you ever thought it would. Maybe the actual core use for the software is now dramatically different. I think it’s hard to back up and really think about the project with a fresh perspective. Question the architecture, question the fundamental design. Maybe the way it worked was right for the time, but doesn’t make sense any more.

This is obviously dangerous, because you can’t simply rewrite your entire code base over and over again (well, you could, but you’d never ship a product). And Ely constantly restated his disclaimer throughout the session, which basically went like so: they’re committed to backwards compatibility, nothing he shows or talks about is decided on, and all your old code that uses the Flex 2 or 3 framework will not be useless. He has to say this over and over because people get freaked out when they see such fundamental changes (which has important implications for all Flex applications ever created). I’m sure that this discussion comes up a lot internally at Adobe, and I’d love to hear more about how that conversation goes.

I’m glad Adobe is keeping backwards compatibility in mind, but what makes me even more excited is to see that Ely’s able to think about the Flex framework with a fresh, innovative perspective. This was what I really took away from MAX: the concept of stripping your code down to core functionality, thinking about it in a fresh light, and not being afraid to change everything.

I hope I didn’t sound like too much of a kiss-ass in this post.