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.
Danger
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.
Nope this was a great post.
As far as I understand if its not written into the player it would remain backwards compatible and because the Flex framework isn’t written into the player, all major changes would remain backwards compatible wouldn’t they?
Hey doug,
Can’t agree more on your post. Ely’s session was awesome and it was certainly not what I was expecting when I first choose this session.
Props to him and the whole flex team for thinking outside the box.
-Boub
Hmm. The only problem now is that I want those features, and they may never come to fruition.
On the other hand, if they do MVC-itize the framework, it will make all of our programs larger, as our code will have to do a lot of what the framework does for us now… and we can’t cache our code in the player.
Crazy thought: Should Adobe decide that these fundamental changes just won’t work with the plan for backwards compatibility, what if they just built a new framework? Yeah, it won’t have the Flex trademark behind it. Sure, some might say it’ll pull business away from the Flex market. Yet, those are stupid reasons for throwing out very good ideas like those that Ely presented.
Tink, you’re right fundamentally, but I think the point was that Adobe wants to be sure that custom components we build today will still be compatible with the new MVC nature that might be in Flex 4+.
Shaun, it won’t necessarily make our SWFs larger. The fundamental component views will be built already, so we can subclass to add special view features that we’ll need. Moreover, if you need to create a completely different view, then it’s probably different enough that you’d have to make a whole new component in the old-style framework (with some redundant functionality), so the SWF size increase might actually be smaller with the new MVC architecture!
Doug, good overview. My thoughts exactly.
The Disturbing…
“When one of the smartest guys I’ve ever met exclaims ‘He’s one of the smartest guys I’ve ever met.'”
Be afraid, be very afraid…and very hopeful!
***
The concern of backwards compatibility just became much less so in many ways with the release of the new Flash Player and the ability to cache the Flex framework. We’ve been given a new means for backward compatibility.
One could declare a Flex app as a “Flex 4” app which would download & cache the Flex 4 framework. So if that list component went from 7,000 lines of code to 1,400. Great! Less download. And if I encounter a Flex 3 app, Flash Player will just download and cache the Flex 3 framework.
AT LEAST somebody talking about Ely’s session. That one was tremendous — When I went out of the session room I told myself : “waoh great time to be a flex developer”… With the things he presented there cannot be NO reason to discard those, backwards compatibility or whatsoever…
I would really lie him to write a blog post of this. At the end of the session time he said he had many other things to present for Flex 4. I would love to read those !
{Maz}
I’m very glad that all of this is considered for future versions of Flex but on the other hand, I don’t see it as innovative thinking at all – WPF and XAML supported this for years. Again, I am very glad to see that graphics in MXML and “lookless controls” are going to be part of Flex in the future but I wouldn’t praise Adobe or any of its developer for doing it – they are just catching up on Silverlight.
By the way, were there any questions about the similarity of this Flex vNext and XAML/WPF/Silverlight? I would love to ask where the inspiration comes from, what they would like to do better than Microsoft, what are the key differences etc. Were these questions asked?
Thanks,
Borek
@ Doug,
Interestingly, Adobe has always taken the approach of allowing their (talented) engineers to evangelize the products. This is smart, because we always get the view from within our own experiences from someone who has been there and done that. Unlike some other companies who have Marketing trying to Evangelize to the developer (Fail!). Ely definitely feels what we are feeling, and that is what makes his view so appealing. Nice to see the lights are on!
@Borek,
What is your point? Who cares where the inspiration is coming from? I create applications every day that are inspired from somewhere/someone/somehow. So, who cares where this inspiration is coming from as long as it is coming. I really do not care if Silverlight got its inspiration from Flash 1.0. I am just glad they had the inspiration to create Silverlight/Flex/Air/WPF and are moving us forward. Also, I personally do not want Adobe/Microsoft worried about differences in their products. I want them worried about what developers need in these products; what productivity improvements can they give us. These are the things that should matter to these companies.
Tony, my point was to say, that:
1) All these improvements are an outcome of healthy competition and from Adobe’s standpoint, it is necessary to answer to Silverlight’s superior programming model. It is not a genius of Ely, it is not thinking outside the box as was suggested above, it is just catching up with the competition. Simple but still extremely useful for Flex development community, no doubt about that.
2) I wanted to ask some questions about the rest of the presentation because obviously not everything was recorded (or shared). If you are not interested in the differences, that’s fine, but I am. And Ely would be one of the best persons on this planet to ask those questions.
I am not trying to be negative and I welcome those changes with big enthusiasm but I had a feeling after reading the post that Adobe is doing something very innovative or something exceptional – which they are not.
Regards,
Borek
I think Borek has a valid point in that we need to acknowledge where ideas and inspiration come from, and in this particular case it might be true that XAML solved the whole declarative graphics stuff far better than MXML did originally, and that now Adobe is adding into MXML what MS got right at the start.
But my point about innovation and why I respect Ely so much has nothing to do with the addition of declarative graphics into MXML. What I respect is the ability to look at the problem with a fresh perspective and be open to changing your approach. I’m not amazed by the concept of declarative graphics (like you said, this has been done before). I’m amazed that Ely is able to look at the current Flex framework and think about how to really make the framework do what it’s supposed to do (make creating powerful and customized RIAs fast and easy), without being locked into the current status quo. That might mean incorporating concepts from other sources or coming up with unique solutions. The important point here is that they’re looking at the framework with a fresh perspective that isn’t tainted by what the framework is and has been for the last 3+ years.
Amen.
I want it NOW!!!
I’ve been loath to learn how to become skilled at doing ItemRenderers and such because the little bit I’ve done has been inordinately difficult. I have a bit of joy imagining using this new way of doing it, but it seems like it’ll be long time until it’s available.
I love the new approach and am excited to see it come to fruition. This would mean possibly smaller component size, exponentially more customizable skinning and styling and behavior. The thing I like about the current component set is the ton of properties and methods they thought of using the constructive approach. I don’t have to reinvent the wheel with the api they include. What I want to know is how they will reconcile the current component features set with this new approach.
So we may get stripped down that are highly customizable components but what about the features that aren’t included in the stripped down version. I suppose they may include an “Accordion” template, “Vertical List” template, etc with the current feature set. Or if they abstracted functionality in a way that we could easily plug it back in that would be cool. I’m talking about adding in features like accessibility, focus management, etc on a need to include basis.
Pingback: dougmccune.com » Blog Archive » We’re not waiting for Flex 4
Pingback: Flex 4 (“Gumbo”) - first details revealed, a bunch of Words, punctuated - by Paul Robertson (http://probertson.com/)
Hi! I was surfing and found your blog post… nice! I love your blog. 🙂 Cheers! Sandra. R.
Sign: umsun Hello!!! rcuwwymhyw and 1212ssgfhphzye and 1178Nice blog!
Pingback: Flash Player 10.1???? - FLEX???
Pingback: ?????-??? || Caoyusky-Blog » Flash Player 10.1????