Just a small comment – I think the definition that a framework should ‘allow(ing) them to build the things that users care about faster and/or easier’ is only one way of looking at it – at the other extreme, you have frameworks that have a bias the other way – i.e. they add a lot of overhead when starting out, but are designed to make it easy to maintain or extend a complex application – particularly in large teams.

The problem is perhaps that a lot of software engineering courses tend to indoctrinate people with the techniques for building complex enterprise software, which are then presumed to be the ‘correct’ techniques.

You should also take a lookt at Parsley:
http://www.spicefactory.org/parsley/docs/2.0/manual/

Interesting post and discussion.

However, I think that it might be a little unfair to discredit frameworks that focus solely on providing architectural/structural guidance. Surely SoC applies here as well: an all encompassing framework/library is likely to get many parts of the puzzle wrong; I would prefer to pick and choose libraries that focus on particular tasks and do them well.

I believe that there is a very good reason why many of the Flash/Flex frameworks focus on MVC (or, on the “structural” side of things): messy, tightly coupled, hard to maintain OO code is one of the biggest problems for developers new to OOP – those from a Flash Timeline background, for example. One can learn how to use any library with a well documented API, but learning how to structure your application, and write clean, flexible code requires a little guidance. I think that these frameworks play an important role in terms of educating developers from less traditional (ie comp-sci) backgrounds. I agree that they provide less value to seasoned developers – especially when the implementation cost is high.

I also agree that the platform needs to advance a bit. Especially with regards to reflection support – constructor injection is tricky for Dependency Injection frameworks to implement, requiring some pretty nasty hacks to function at all.

A summary of my thoughts on some of the “big players” at the moment can be found here:

http://shaun.boyblack.co.za/blog/2009/04/29/another-architectural-framework-but-why/

And my “me too” Flash/Flex framework:

http://shaun.boyblack.co.za/blog/2009/04/16/robotlegs-an-as3-mvcs-framework-for-flash-and-flex-applications-inspired-by-puremvc/

@James Polanco: DevelopmentArc looks very cool – I’ll be sure to check it out soon.

Interesting discussion.

I’ve had similar thoughts (I think) to yours concerning a ‘Global Event Bus’, but what you’ve written confuses me. ‘Omitted’ means to fail to include … when I initially read I think I translated ‘omitted’ to ‘emitted’ and things made better sense. Anyway, just semantics, be important at least in my understanding.

In my thinking I hadn’t broken down events into four categories, only two. 1) Macro (i.e. Global) and 2) Micro (i.e. of concern only within a component. I think my thoughts are on a parallel line to yours however, in that I would like higher level event abstraction and standard use (like provided by Mate), but would like to be able to implement it in a contained ‘micro’ scenario without dependence on any ‘macro’ constructs. This would provide for better encapsulation and re-use of components created (with something Mate like) in larger systems based on other frameworks. At present, it seems that only managing and implementing with native events at the component level allows for this type of reuse.

Just my 2 cents, but very interested in your thoughts.

I like that you plugged Swiz (and I’ve recently discovered Chimp–something badly needed for awhile now), but after I read “client side Hibernate” I threw up all over my keyboard and monitor, and killed myself. =)

Ok I lied, but please, no more heavyweight or “magic” frameworks that are impossible to fully understand unless you were on the development team, destroys performance, and which has a new “improved” version every year, making your code obsolete and getting support for the framework near impossible…….

I do agree (if you’re saying this) that MVC has seemingly (as many things in IT) become a goal in itself. People in IT often seem to forget that our techniques and standards need to be re-evaluated often as things change, to make sure that their intended purpose is still being met in the best way possible. Often I think people in IT lose sight of the end goal of getting the job done, and we end up with “crap hacks built upon more crap hacks” which works–but then if you compare to what it would have taken to just do the work the old fashioned way, there’s little difference in time or productivity.

I like that you plugged Swiz (and I’ve recently discovered Chimp–something badly needed for awhile now), but after I read “client side Hibernate” I threw up all over my keyboard and monitor, and killed myself. =)

I think that maybe my favorite comment ever left on my blog, and there is a part of me that agrees with your point. The black box that frameworks like Hibernate introduce into a project can be a major issue. That said, I do think they have a place… There are times where they are very effective and offset the cons.
Thanks for the comment,
Jon

Glad you “get” the sense of humor.

There may be times that ORM works just as well as simpler approaches. The question I always ask though, is whether heavy ORM users actually realize exactly how much time they spend dealing with the “special cases”, additional troubleshooting due to the increased complexity, application bugs caused by incorrect use of the ORM tool, dealing with actual bugs or shortcomings in the tool, performance tuning, increased overhead getting someone new to the team “ramped up” to use the tool, and time spent researching/learning/reading documentation for ORM.

It’s difficult to actually quantify the real return on investment for these tools in comparison to just sitting down and doing it using a more tried-and-true, complexity free method. Few people seem to think about the hidden costs of a more complex system, because on the other hand, you can plainly see the costs of a simple solution–but I see this as a good thing.

To me, all that effort could have just been spent using Spring’s JDBC Templates or other more basic tools, and you’d end up with a simpler and faster end result that even a cheaply paid college grad fresh out of school could understand, or a DBA could easily assist with (sql wise), should the need ever arise. I figure, sometimes it’s better to just do the work and get it done than to try and come up with the ‘Next Best Thing’ simply to avoid a little work– nothing in life is free!

But this is just IMO. Sorry this grew to an essay.

Actually, speaking of Swiz, my war against heavyweight “frameworks” and complexity is the reason I locked onto that little architecture once I found it.