On Flex Frameworks. Twitter Style.

BBC has a nice way of presenting news – I believe it’s called “No Comment”. The viewers can watch some happenings in silence without hearing any comments. I’ll borrow this technique and will present you a Twitter “conversation” that started after I made a statement about MVC and Dependency Injection frameworks in Flex. I’m planning to prepare a presentation explaining my position for the Fourth Annual Farata Flex Symposium that will take place in June in New York City, but for now, enjoy the twitter conversation without comments. I’m going to use abbreviated Twitter nicks of people who responded to my twit – the rest are original twits.

There are 4 types of MVC/DI Flex Frameworks people: creators, evangelists,users,and myself who can’t get what are they for. #flex
@b… What?
@b… again, what?
@bp…Ummm… I think you’re probably a creator if you’re not one of the others. Over and over again, too.
@_… Amen :)
@h…You don’t use it or not recommend any flex framework?
@j… DI itself or just the frameworks? I kind of agree with you on the frameworks, I try to only use the [Inject]
@yfain Not in general, specifically in Flex frameworks
@f… count me in 😛
@j…In my case, I (almost) refuse to develop without MVC / DI in client-side development.
@bp…They’re also great for learning… every MVC/DI framework I’ve used on any platform has taught me something new and valuable.
@_… The Flex Framework Frameworks only result in higher dev costs. Complexity up, Qualified devs down. :)
@yfain Exactly, Ted :)
@_…That said, I am finding that robotlegs might be the exception… :)
@yfain While MVC/DI frameworks can be good in Java EE world,they damage minds of Flex/AS developers. Pros: they keep consultants longer on billing.
@b… I see – I must have forgotten, best practices are only for Java. How silly of me all this time, leaving behind maintainable code…
@bp…Can you give an example of bad habits or practices we’re learning?
@yfain Wrong. You’ve forgotten that Java is a language while Flex is already a framework with a great event model.
@b… wrong. flex as a framework doesn’t address the need for application patterns. the free for all approach doesn’t cut it
@neosavvy It is true. Vendors use design patterns to hide low qualification and prove legit design to clients who don’t know how to argue.
@m… you honestly can’t see a need for DI? Ever write a unit test?
@b… yakov’s just out trolling again. Don’t worry about it too much, he’s warned that you’ll “damage your mind” in the process
@yfain what’s wrong with using events instead of DI?
@m… How would you use an event to provide dependencies to an obj? Injection is a means to allow isolation which is a precursor to tests
@yfain An object is listening to events. There are no dependencies.
@n… I find this conversation hilarious because I think the statement “keeps consultants longer on billing” might be true wrt DI in Flex.
@yfain It is true. Vendors use design patterns to hide low qualification and prove legit design to clients who don’t know how to argue.
@n…Isn’t that how Cairngorm got so prevalent? I agree that design patterns may be for the weak minded. Useful for handoff and support.
@yfain De mortuis nil nisi bonum. Speak no ill of the dead
@i… I’d really like to see some examples of the proper way of doing things without frameworks in Flex. Think you could post some up?
@yfain Start here http://bit.ly/dQPywI

Yakov Fain

12 thoughts on “On Flex Frameworks. Twitter Style.

  1. Gotta say, you’re offbase on this one. A strong messaging model does not completely replace the need for other dependencies within an application. And while flex is an a Framework, that doesn’t mean it solves all common problems within UI development. Also, discussions like these could do without some of the more contentious things you ended up saying.

  2. This is quite the hot mess of a conversation on frameworks. If you write a medium-large scale app in Flex and don’t use a well publicized framework, chances are you are just re-inventing the wheel. Design patterns for the weak minded? The worst is when maintaining someone else’s code because they did it their own egotistical way instead of structuring it in a commonly recognizable way. The reason why it’s the worst is that you have to endure the overhead of analyzing why did they do it this way when they could have simplified it in a more common way.

    Some people are so anti-framework that they don’t realize that their own initiatives require just as much overhead to learn them as it would to learn a well known framework.

    My background experience is not a vendor of software but a developer of Flash Platform products developed by teams of front-end developers.

  3. IMO, the problem is that instead of spending time learning best practices and features that Flex framework already offers, people simply pick up one of the third-party frameworks and spend time learning it. I can’t understand why though. Each of the third-party frameworks offers you its own way of passing data between component/module A and B. In addition to it they dictate what to use as a common data storage (the model) and how to call a remote service. But all this can be done in a pretty standard way that is offered by Flex framework itself, and if a team of application developers would bother learning it everyone would be writing an easy to read code.

    I’m not anti-framework because I just don’t like frameworks in general. I’m just having hard times understanding the ROI. If I’ll spend 2 days and learn a set of annotations/classes/metadata tags of the XYZ framework what am I getting other than replacing the original Flex syntax with another one? I don’t have problems with using tools that save time and make me more productive. But using a MVC/DI framework just because some developers ported ideas of distributed Java EE applications into a domain-specific front-end tool doesn’t sound right to me.

  4. Personally I believe the ROI on adopting a framework is not just replacing the sufficient Flex Framework but creating a standardized environment for rapid and relatively maintainable features. I do agree that learning the Flex Framework inside and out you will grow to appreciate the Event model more so. However, on a team you are going to have people of different experiences who will interpret this model in their own subjective degrees. I say this loosely, but no 2 projects that don’t use an msging framework will have the the same ramp up time for an on boarding developer despite both projects using the same Flex Framework. Whereas the advantage of a common framework, that friction is reduced to as low as possible.

    Having worked on Flex since version 2, I think we can all appreciate how malleable it is to get the desired changes on the UI. I believe frameworks add a sense of rigor required to get multiple developers up and running on the same page.

    If the Flex Framework was really sufficient enough as you believe, we wouldn’t have the ecosystem of frameworks that we have today.

  5. As for best practices, it’s unfortunate that each developer house it’s own take on the “best practice”. For example, once place likes to push their data and sees it wrong to pull it in. Another house will say pulling is better than push.

    Frameworks, I have to confess removes you from this debate. Not necessarily make you dumber for it but the trade off is that team doesn’t have to waste time debating it.

  6. Mark, I hear you. But I prefer educating developers of various skill levels working on the same project. It’s pretty easy to have a team agree on a set of best practices while working with the Flex framework. But these micro-architecture frameworks eliminate debates by bringing all developers to the lowest common denominator – the lowest skilled developer who just knows how to map events to commands or mediators.

  7. Yah, man. you hit the nail on the head.

    Re: “I prefer educating developers of various skill levels working on the same project. It’s pretty easy to have a team agree on a set of best practices while working with the Flex framework”. I had to LOL at that. In some workplaces, one can only dream because it was not the place nor the seniority to defy set practices nor the budget to entertain to debate what is right.

    You might think differently but I for one would not undermine the power of getting the lowest skilled developer to map commands and mediators. 1) The team moves faster when they’re on the same page and 2) you don’t have the lowest skilled developer trying to be a hero doing their own thing at the expense of the project/product.

    I agree whole heartily with you the same goals can be accomplished without 3rd party frameworks but you are trading off the time it takes to train that dev to the level you need them to be at. Not everyone wrote a book called the Master of Flex or Java, has course material or has speaking engagement experience to shape resources to where they need to be =)

  8. These comments are exactly right. We could talk for hours on end about what a “best practice” is and why it is best but that is definitely not the only objective of a micro-framework or MVC. In my experiences, developers come and go but it is what is left behind that matters. Unless your current “Senior Flex Developer” (as if ALL your devs don’t have that title) has some of the most disciplined documentation habits ever witnessed, you are way better off having a structure that is documented by someone else. By removing the influences of a coding-jock that has die-hard beliefs that a single 9,000 line model is the way to go, you ensure that your code is far more manageable and more quickly understood by new talent.

    I also think that these micro-frameworks help scripters become programmers. Junior devs don’t need to know why the command pattern exists. They just need to know how and when to use it. After a while, the “why” becomes more obvious and now you have a Junior+ developer.

    I am new to my current position now and have already gotten into rather “intense” conversation with the current lead who has owned the code base for the last four years by himself. It is frustrating coming into code where the architect didn’t believe in VOs, command patterns or service patterns when all of my past experience implemented these metaphors. I only wish the was a Wiki called “MyCurrentFlexArchitectsFramework” so I could see some examples….

  9. 1. MVC and DI are two different things.
    2. Have you ever used Spring in Java ? Hibernate in Java ? JDOM in Java ? Or do you re-invent the wheel every time and hand crank your own ? That to me is a way of extending consulting time.
    3. Given your assertion that frameworks are just there to lengthen consulting time, I assume you wouldn’t advocate using the framework mentioned here: http://flex.sys-con.com/node/856150 ?
    4. Since when has dependency injection been for the exclusive use of a distributed enterprises environment ? Dependency Injection is about separation of concerns/responsibilities and hence is just about good software engineering practices. Its exclusiveness or suitability to JEE is no more or no less than its exclusiveness to Flex.

  10. @Tony Why do you think that there are only two types of developers – those who use micro-architecture frameworks and those who don’t? There is a huge layer of Flex developers between the two.

    Based on my experience this is not the case “Junior devs don’t need to know why the command pattern exists. They just need to know how and when to use it. After a while, the “why” becomes more obvious and now you have a Junior+ developer.”
    I see that people who just know where into which class put their business logic remain junior developers for a long time.

    1. I’ve heard that MVC and DI are different things. But in the context of this blog we can talk about both of these patterns together.

    2. You are comparing apples and oranges. Java is a programming languages and adding frameworks is understandable there. But building a framework on top of Hibernate would raise some questions. So building another framework on top of Flex framework is what I’m questioning.

    3. We don’t build micro-architecture frameworks on top of Flex. We build tools. Our Clear Toolkit is a set of code generators that builds a CRUD helping developers writing less code while all MVC/DI framework ask developers to write more code manually just to put a structure on the project. BTW, Clear Data Builder 4.2 (http://cleartoolkit.com/dokuwiki/doku.php) can automatically generate CRUD hooked up with Hibernate and Spring on the Java side. We save time of enterprise development making our consulting gigs shorter. Stupid us :)

  11. I am re-reading but I don’t see where you would think that I believe that there is only two types of developers. Developers come in a wondrous variety! Nor did I mean to imply that the soul act of interacting with a command pattern would make a expert out of a junior. In fact, all I said is that it would make a junior+ (can be read as “better junior”). However, unless you have time to hold their hand through your custom architecture, I would recommend using a community supported architecture so that the resources (documentation, examples…) are readily available via Google.

    Juniors remaining juniors for a long time can be caused by a lot of things. Maybe you didn’t give them enough of your own time? While you are obviously capable of designing your own custom framework, the rest of us seem to learn from the best practices of others. Working with frameworks designed by a collective of experienced developers is a great way place to start building your own opinions and ideas.

    I have nothing against NOT using a micro-framework. In fact, I would argue that some of the best architectures I have seen didn’t subscribe to any micro-framework at all. But they were not easy to understand, they were not well documented if at all and they were more than just a little challenging to new developers of all skill levels.

    The usefulness of micro-frameworks really depends on the team. If you know that you will be responsible for this project for its lifetime, by all means, architect it however you see fit. But if I was the owner of the company so I REALLY owned the application, I would see a lot of value in a code-base that would look familiar to most any Flex developer.

  12. Flex is mainly just a component/layout framework. Not using a good DI framework is fine for a small or even medium sized project but for big enterprise projects, you’re just shooting yourself in the foot when not using one.

Comments are closed.