The old goat bites back
July 12, 2009 at 4:47 am 8 comments
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 way of doing things.”
If someone doesn’t know about software development, then Flex is great. It’s ok for dragging together a quick application that exploits the components in the limited way they were intended. But as soon as you want more customised behaviour – it’s quicker to code from scratch with Pure ActionScript, than to wrestle with Flex idiosyncrasies. And I know these idiosyncrasies better than most people.
In my professional capacity as a senior Flex developer – I’m always getting asked to do with things with Flex components that Flex components don’t do. Ok coding custom components and objects may be an “old way of doing things”, and being an experienced software developer and AS3 expert may make me an “old goat” – but it gets the job done, and I get paid very well for it.
In the early days, the market for Flex was predominantly existing Flash developers. They probably didn’t delve as deeply into things as programmers do. But now, I suspect that a lot of experienced software goats are moving to Flex. I don’t think Gumbo went far enough to accommodate for this new user base.
The bloated swiss-army-knife monolithic components were written to be manipulated inside the Flex GUI – they were NOT designed to be inherited and extended by a programmer.
Anyway, since when is Flex a new idea? It’s like Visual Studio for ActionScript. I hate .NET more than I hate Flex. Jones is probably too young to remember when Visual Basic first came onto the scene. The problem with these drag-and-drop software making GUIs is how they handle the transition to more customised behaviour – Flex does not handle this well.
Buggy, bloated and badly conceived is not a new idea either.
Entry filed under: Flex sucks.
8 Comments Add your own
Leave a reply to e2easy Cancel reply
Trackback this post | Subscribe to the comments via RSS Feed
View my profile
e2easy AIR applications 
1.
ronnie | July 12, 2009 at 8:43 pm
lol, “i’m a super flex dev and i do magic” i would like to see you building an advanced data grid in an old way. not knowing how do deal with existing components clearly shows you have no clue how flex works. and yes, i know you won’t publish this.
2.
e2easy | July 13, 2009 at 3:50 am
Of course I’ll publish it Ronnie. But you really should have followed some links to my applications or career history before shooting your mouth off.
Anyone who knows anything about Flex would never choose the AdvancedDataGrid as an example to exemplify its merits. That was bound to get you in trouble lad…
I’m going to write a follow-up blog-post to answer you fully, and recount some of my adventures with the ADG. Watch this space.
I welcome all comments. (The only ones I don’t publish are when potential clients initiate contact through my blog). I especially welcome viewpoints that differ from my own. It helps spark debate. But you’ll notice that whenever I say that “Flex sucks” I always say WHY it sucks. It’s a pity when blind-faith dumb Flex evangelists respond emotionally.
Flex evangelists- please take the time to engage your brain, read the specific arguments I’ve made and construct an intelligent counter-argument.
3.
Tink | July 13, 2009 at 7:33 pm
“But as soon as you want more customised behaviour – it’s quicker to code from scratch with Pure ActionScript, than to wrestle with Flex idiosyncrasies.”
I have to disagree. For me the Flex framework (and components) provide a great base to extend for custom behavior. I agree that sometimes its a little awkward due to methods and properties marked private but a quick monkey patch always gets round the issue, which for me is better than starting from scratch.
The more I work with different components the more I learn about how they were built and how I can manipulate them.
My brain is engaged and starting from a blank sheet seems like I’d lose a load of useful stuff I’d want to inherit.
4.
e2easy | July 14, 2009 at 3:54 am
I’ve also monkey patched Flex components and delved into the way they are written. But it’s a really bad idea. You’re not really using Flex in the way it was intended. It’s violating the intended interface. Worst case (but unlikely) scenario is that Adobe will change something in the next release that will break your job. But the fact that changing private behaviours is often the only way to customise a component only supports my argument that the “components were written to be manipulated inside the Flex GUI – they were NOT designed to be inherited and extended by a programmer.”
I only use Flex for commercial projects, sharing code with other developers using SVN. This can make monkey patching inconvenient. You don’t want to share the entire Flex component library. (Or is this what other developers do?). I’d like to leave the source intact anyway, and just copy and modify classes that I’m changing. But there’s a problem with that. I once tried to monkey patch the AdvancedDataGrid, but there were a slew of dependencies, so many classes to copy and modify, that I had to abandon this approach.
I get your point about the blank sheet. I have to admit that my pure actionscript developments don’t start from scratch. I started writing ActionScript components in 2001. By the time Flex came on the scene – I didn’t need it. I had scrollbars, buttons, menus, rich text editors, very powerful grid based components… all written to be extended by a programmer. No monkey patching required.
5.
jones | July 14, 2009 at 7:29 am
Well just for the record.. I pretty much agree with your main points, in the sense that there is MUCH room for improvement in this area. I get quite frustrated with it at times. Where I disagree, is the overly simplistic assertion that Flex is just a hindrance and bare-bones AS is better.
As you said yourself, you have a library of components developed since 2001. Well, most of us don’t. People that have extremely deep, intimate knowledge of a technology will typically (and somewhat understandably) shun new technologies that attempt to sugarcoat the thing with new layers, design interfaces, etc. because these things tend to limit access to low level functions, add bloat, etc. I get it.
I would say that maybe Flex is a hindrance for YOU… but not for a majority of people who want to develop apps for the flash player. I also disagree on the ‘only for simple apps’ suggestion. It depends on what you mean by ‘simple’. If you insist that every one of your components succumb to and behave according to your every whim, then yeah, probably need more control than Flex gives you. But if you’re going to balance your UI requirements by conforming to or dealing with Flex component limitations/quirks/etc… because you have a *complicated* application that doesn’t require a bunch of non-standard components, then Flex may be terrific (as it has been in my case). ‘Complicated apps’ doesn’t always mean complicated, highly customized UI.
So anyway.. my original response was mostly directed at your last comment (which I didn’t realize was you, the author of the blog entry, which I didn’t take issue with at all). Re-reading it, I notice that you qualified your statement with “if you delve deeper” then Flex is a hindrance… which I can agree with more.
I was thinking something along the lines of….
“If you’re an Actionscript ninja with a decade worth of deep experience and have a comprehensive library of custom components and/or your application UI requirements call for extensive custom/non-standard behavior, then you may find that Flex hinders more than it helps.”
However, if that requirement comes up, I’m not spending a couple years becoming an AS master. I’d jump over to Silverlight before I did that.. which would not make me happy as I’ve already made a heavy investment in Flex.
The LAST thing on my wishlist for Flex 4 was skinning and 3D… which seems to be about the only focus. Very disappointed.
6.
e2easy | July 14, 2009 at 6:05 pm
I’m quite enjoying wearing this persona of the “Old Goat”. I’m going to keep using it.
I use Flex (+custom coding) for commercial projects, and pure-actionscript for my own stuff. But I’ve got so much work lately that most days +weekends I’m immersed in Flex. I wish I could shun it. 🙂
7.
Tink | July 14, 2009 at 9:12 am
I’m not saying monkey patching is great, that said if you are really so against monkey patching the odd file, to get all the other addition benefits from Flex:
Styling
History management
Popup layer
Effects framework
Invalidation
Built in preloading
Drag and drop management
MXML and delayed instantiation
Liquid layout
Binding
Useful formatters
Logging
Tooltips
Modules
States
Validators
…you could give the file a different name in a custom package.
In response to you comments re monkey patching
“Worst case (but unlikely) scenario is that Adobe will change something in the next release that will break your job. ”
This may be the case, but your project will be pointing at a particular SDK, so as long as you stick with that SDK there shouldn’t be a problem.
Sharing code over SVN shouldn’t make any difference to monkey patching? It’s just another file, but in a package that matches one of Adobes.
That said I’m not saying I have projects that have 20-30 monkey patched classes, but now and then in projects I require the odd one or two.
“But it’s a really bad idea.”
The best argument you have to support its a bad idea is that Adobe might change something that breaks it in the next release, which you then go on to say is unlikely.
I guess its each to their own, for you its only useful “for dragging together a quick application that exploits the components in the limited way they were intended”. For me, as I learnt more and more about it over time, its a killer framework (soon to get a decent updated), for building complex custom applications on top of.
8.
e2easy | July 15, 2009 at 4:59 am
I don’t like monkey patching, not because of the future updates, breakages, etc. Simply because it violates the intended interface.
I’ve indoctrinated university students into the merits of Object Oriented methodology and abstraction. I could hardly condone overriding private methods. But I’m pragmatic, and if it’s a quick fix, without a slew of dependencies – I’ll do it.
Most of the benefits you listed aren’t really benefits. They’re Flex concepts, only applicable within the Flex mindset. In actionscript, you’d pass it by on the periphery of coding something-up, and not even think too much about it – with no significant cost of performance or file size.
(and Preloaders are much more important in the bloated Flex world than with Pure-ActionScript.)
Even when I’m working on a Flex project, the performance of the Flex way is so poor that I have to go down the custom coding path. The PopUp manager class, for example. It’s slow, and I’ve had problems with Flex popUps inside an ADG headerRenderer.
Application.application.addChild(myPopUp); is easy and fast.
I think the use of Flex has changed, but it hasn’t evolved fast enough. When Flex was first released, there were so many applications we didn’t see – they were inside organisations and hidden within intranets. Internally, we can tolerate the poor performance and components that aren’t as user friendly as they could be. But when you create something for general release, the production values are higher.