I’ve just been taking a look at a well-known framework that deals with command-driven code. Whilst having a read of the docs and seeing what’s what, I was thinking “this sounds handy, this could solve a lot of problems”. I then installed the framework, and was stunned when I was then looking through a multi-file/component lump of code that did a “Hello World!” example. Sure, these frameworks don’t shine when doing simple examples – but I am having trouble seeing where most of the benefits of frameworks lie.
A lot of these frameworks deal with abstraction of code so that code A doesn’t directly use/know about code B etc etc, when in reality what you end up with is the big bunch of files passing all sorts of variables and objects around to acheive things that could be written in Plain Ol’ Coldfusion (POC) in a matter of a couple of lines.
For instance, proxy objects. Why create code, that wraps other code when you could just make the location of the original code a configuration variable? Another one – why spend ages making a framework understand complex objects in configuration when again, you can just write it in POC nice and quickly without having to get bogged down in a framework?
Personally, I think we had it right around Fusebox 3-ish times. A load of MVC code all based around a central controller, and a config file (which was CF). No XML, no gateway objects, no framework loading, just a straight forward bunch of code that was easy to read and understand, simple enough to be Agile, and best of all extendable in whatever way you wanted (you just had to write the code).
Now, I’m not dismissing frameworks completely – Model-Glue for instance has it’s benefits, but personally I’ve never seen why anyone would want to get as complex as Mach-ii etc. Half the time, a lot of these frameworks appear to be code for code’s sake – a way of satisfying a coder’s needs as opposed to those of a more pragmatic programmer….
Bring on the flames….
I agree 100%. I’ve been fairly excited about the commotion surrounding Steve Nelson’s comments that are a lot like yours. To me a framework is just one guy sharing his own methodology, and hoping everybody else will use it.
I don’t know. I mean – you said that these frameworks end up passing a lot of stuff around. In Model-Glue, that stuff is
a) input parameters (form, url)
b) things needed for the view
So for a – the abstraction means you aren’t tied to form or url scope or have to worry about updating code when you switch. As for B, having a API to store variables safely (which to be fair, is mainly like the Request scope), makes it simpler to deal with on larger web sites.
You couldn’t have said it better! In my opinion FrameWorks are becoming popular now because of the .NET frenzy. “Since Microsoft is OO, now everything has got to be OO.” It would be nice if people could take a couple steps back and question what best practice is before blindly assuming Microsoft is the way to go.
@Jacob & Bill – Blimey, someone agrees with me. I thought I was in the minority considering the traffic I see floating past on feed-squirrel.com
@Ray – I agree with what you are saying, but to be honest a lot of it seems to be abstraction for abstractions sake. None of what you have mentioned are things that I would have considered as even remotely difficult even back in the CF 3 days. I would argue that frameworks probably add more overhead to a developer (day to day) than doing it in a more home-grown sort of way and re-using where appropriate.
My suggestion would be to go beyond a simple ‘Hello World’ example before you form an opinion of some of these frameworks. Just think of what would need to be done in Fusebox 3 for a ‘Hello World’ example.
Where frameworks tend shine is in large or complex applications. Using a ‘Hello World’ example to judge some of the new, OO-ish, frameworks is like judging a scientific calculator by how well it can do ‘2 + 2′.
I have to agree with Ray here. I’m not sure what is so complex about the idea of an Event object encapsulating the form and url scopes. Fusebox 2 and 3 did this with the attributes scope. All three now have an event object. The point is that your code doesn’t need to know or care whether incoming values are form or url variables, which is a huge benefit.
I’m not sure what else any of the three main controller frameworks do to make you “pass around all sorts of variables and objects”. The way you’re talking about Proxy objects makes me think you’re referring to the Facade and Adapter patterns, which really don’t have anything to do with Frameworks at all.
I don’t think any of this is abstraction for abstraction’s sake. I suppose its inevitable that over time some people forget why these kinds of abstractions were developed and what the pain points were. That’s ok…I don’t think it will take long for them to remember.
@ Brian and Scott
There may be some cases where OO programming is beneficial. However from my experience, making something OO just to make it OO greatly takes away from simplicity. Especially ColdFusion. Let’s not forget that it was designed with simplicity in mind. Stuffing it into a framework in my opinion greatly defeats its original purpose.
Another example, look at all the frameworks out there for Ajax. It’s freaking ridiculous; an AJAX call only takes 5 lines of JavaScript code! However now that everyone is trying to push their latest and greatest framework, it now takes hundreds (if not thousands) of lines. Abstraction for abstractions sake, naawwww. I look at it more as overly anal retentive developers trying waay to hard to separate code from presentation and trying waaaay too hard to mesh academic concepts into real world applications. Good luck continuing to fight that battle, guys. Someday you will have total separation, I’m sure.
I don’t think we have to say OO here. I write MG apps and they are not OO. There is no inheritance, no interfaces. I do make use of CFCs, but CFCs are NOT OO.
Frameworks != OO don’t forget.
Thanks for the clarification Raymond. It’s pretty easy to confuse framework and OO terminologies since they’re frequently used together.
We use Cairngorm with Flex here – and the main reason we do this is simply that it’s the most common framework for Flex and therefore if we need to recruit for Flex developers, we can recruit from those who are already familiar with this framework – and therefore will immediately be able to grasp the basic structure of the application code.
For me, this is the best reason for using a public Framework there is.
Jamie.