Gumbo. Substance behind the hype?
June 4, 2009 at 6:47 am 9 comments
Just like everyone else, I downloaded the public beta of Gumbo as soon as I found out about it. But is it better than its predecessor?
My biggest problem with Flex is the components and the framework. I hate Adobe’s bloated swiss-army-knife software approach. I waste so much time struggling with Flex components, trying to get those monolithic beasts to behave in the way I want them to.
In the pure-actionScript world, I deal with small and efficient fit-for-purpose components. If something doesn’t quite do what I want, I inherit it and override or add what I want it to do. Everything is small and easy to understand. (No wading through hundreds of methods and properties in the Flex documentation or source code).
Hence developing an application in Pure ActionScript is ultimately faster than Flex. Flex Builder may initially look easier, with its drag and drop interface – but that’s deceptive. But Pure ActionScript development is faster in the long run because Flex is a blunt instrument that’s inept at crafting the details.
So this was the issue I expected to be addressed in Gumbo. I’d heard about the new “Spark” components. The word “Spark” carried connotations of “lightweight”, and “rapid”. So I was hopeful that Adobe were moving away from Swiss-army-knife approach, in favour of something that empowers the programmer and their Object Oriented methodology.
But it doesn’t look like Gumbo gave us anything like this. It will take a while for me to determine whether Gumbo is an improvement for the programmer (apart from the workflow with the graphic designer ).
Entry filed under: Pure ActionScript.
9 Comments Add your own
Leave a reply to The old goat bites back « e2easy AIR applications Cancel reply
Trackback this post | Subscribe to the comments via RSS Feed
View my profile
e2easy AIR applications 
1.
Ryan Campbell | June 4, 2009 at 5:16 pm
Flex 4 only partially solves the “swiss-army-knife” approach that you talk about by separating the view/skin from the component logic. The component no longer makes any assumptions of what you want it to look like.
The next step (hopefully Flex 5?) would be to separate the behaviors of the component in to its own layer, allowing you to add/remove/swap out default behaviors with your own implementations.
Although I was hoping Flex 4 would have done this, I’m at least happy Flex is headed in the right direction. Adding support for swappable behaviors to the SDK and Flash Builder is a fairly large task that could take up an entire development cycle.
2.
Jason | June 4, 2009 at 5:32 pm
I couldn’t agree more with what you’ve said about the Flex framework. Though I’m not sure I’m going to be programming up my own datagrid anytime soon…
I’ve really only done one major Flex project so far, and I was often left wondering how the framework was helping more than hindering for a lot of that time. Obviously my lack of experience with the components and an understanding of what they can and can’t do has played into that, but for a first timer I was left with a bit of a sour taste in my mouth. There’s a stage 2 for the project I’m working on, and this will involve a good deal of design work. I am hoping I can transition from Flex 3 to 4 relatively easily and use some of the improved skinning abilities that I’ve heard so much about.
3.
Tuomas Artman | June 4, 2009 at 5:53 pm
“Hence developing an application in Pure ActionScript is ultimately faster than Flex”?
You probalby haven’t used Flex on the right projects (usually a bit larger and data driven). It takes some time to understand the beauty of Flex, but after two or three projects, you’ll notice that it cuts down on your developent efforts big time.
4.
Daniel Wabyick | June 4, 2009 at 10:26 pm
Flex 1/2 were originally designed for non-Flash developers to dive in and be able to create applications quickly and easily. This, it definitely accomplishes.
The challenge is when the apps want to be brought to a level of refinement beyond the default skins and behaviors. In early (and arguably current) versions of Flex, getting UI components to look and behave as easily as pure Flash was difficult.
Pure Flash, however, can be treacharous for larger applications. You need a deep understand of low-level Flash, as well as OO programming. Few people have this ability. Its easy to create Flash apps that spiral out of control quite quickly. Flex, I would argue, has more design patterns that make sense to OO developers.
I like to thing that Flex 3 accomplished the 80/20 rule of development. 80% of tasks were easier, but the last 20% could be quite difficult. And 80% is a B-, and nobody wants that. 😉
From what I’ve seen of Flex 4 so far (I’m still learning), its getting closer to 90/10, especially when you add in the improvements in Designer-Developer workflows. I think the proof will in the quality of Flex 4 apps.
In full disclosure – I work for Adobe, although my role is as a consumer of Adobe’s products (I’m not on the product teams). I hope this comment lends some perspective to the above post.
5.
James | June 4, 2009 at 10:27 pm
> You probalby haven’t used Flex on the right projects
> (usually a bit larger and data driven). It takes some time
> to understand the beauty of Flex, but after two or three
> projects, you’ll notice that it cuts down on your developent
> efforts big time.
I have been using Flex since the start. I’ve used it for many projects, know Flex backwards, inside-out, and am Flex certified.
YET… I have to agree entirely with the above statements by this blog author. Working in pure Flash gets me there faster, with a leaner, better outcome.
I am doing less and less and less Flex work have been switching back to pure Flash more and more. Personally, I don’t see much in Flex that means faster development times. Binding… big deal. Takes me a couple of seconds to do the same thing by hand, and those are the kind of things that rarely need to change. Skinning… big deal. I can do that in straight flash as well using graphical or programmatic skin files.
Developing in straight Flash takes a lot more skill than Flex (which holds your hand all the way) but if you are architecturally solid and able to craft software well, then straight Flash is the superior choice any day — fast loading, lean, mean and a very sharp instrument.
We find Flex is perfect for back-end site admin stuff and utilities. For those it doesn’t matter too much if you have a slow loading, semi ugly but functionally sound application.
6.
e2easy | June 5, 2009 at 3:52 am
(author’s comment)
For the record, I’ve been using Flex Builder since the first beta that ran on the Mac. But I was writing sophisticated ActionScript applications for a long time before that.
The flaw in the “80/20 rule” is that it assumes that new Flex users are migrating from Flash. Initially, this was true – but not any more.
I run a Flex conversion course for people with programming expertise. Mostly Java experts.
These are the kind of people migrating to Flex now. Experienced software engineers. But Flex was never conceived with these people in mind. Initially, it looks fun and easy to use, drag-and-drop. But delve deeper, and Flex is more of a hindrance.
7.
jones | July 11, 2009 at 10:28 pm
Flex a hindrance? Only for old goats who sneer at changes to their old way of doing things.
8. The old goat bites back « e2easy AIR applications | July 12, 2009 at 4:47 am
[…] 12, 2009 In reply to my previous post Gumbo, Substance behind the hype? – Jones wrote ”Flex a hindrance? Only for old goats who sneer at changes to their old […]
9. Elvis DAM – New Flex – Gumbo | March 28, 2011 at 2:58 pm
[…] Others have blogged about the most important features in much more detail than I ever could, so here are a few good reads if you are thinking about upgrading to Flex Gumbo: “Top 10 Flex Changes”, “What’s new in Flash Builder 4 beta” and more critically “Gumbo. Substance behind the hype?“. […]