Here are the answers to your questions (in no particular order): Yes, No, Yes, Yes, Maybe, It depends, Yes, Yes.

But seriously... I don't think its a matter or "better", "smarter", "cooler" or any of the above. It's about writing code in an organized manner that follows a particular methodology so that it is easier to build and maintain (IMO). So if your framework does that for you, so be it. Model-Glue (my framework of choice) does that for me, and it allows any other MG developer to hop into my code and *immediately* figure out what is going on for a particular event. There's no guesswork at all. You want to know about event "foo.poo"? Go to MG.xml - find the event - see what it broadcasts - see what is happening in the controller - see what views are included -- all of those things are standardized. No more guessing where variables are set, etc.

Its a matter of following a pattern for maximum reusability. I can take anyones MG app and support it with 10 minutes of ramp up time - instead of 10 days. Are there performance implications? Maybe. But I'm inclined to live with that for the sanity of a well constructed application. I could be wrong, but I find it hard to believe that the pig latin demo took 1s for every request.

Do what you like, but to me the biggest benefit of a framework is consitency, reusability, etc.

@Todd,
I'm in the other camp to a degree. One of the reasons I don't care for many of the mainstream frameworks is that it really limits the people that can be dropped into a project quickly. So instead of being able to grab someone who has basic cf knowledge and is relatively sharp, I have to find someone with specific framework experience.

The other big issue I have with frameworks is that, without exception, every framework project of size that I've ever worked on has not followed the framework very well. There tends to be lots of rogue code that just doesn't follow the rules. Sometimes that's because the developers didn't understand how the framework operated and just needed to "get it done". Other times it's because lots of framework code exists from old versions and a new framework has been implemented on top of the old code. It can be pretty maddening.

Dont' get me wrong, you can have some real nasty problems with non-framework code, but it doesn't seem to get as scattered. A framework that you are not familiar with can make tracing things back to their origin very difficult, especially if the framework is not followed consistently. One of the old fusebox apps I worked on had gobs of logic buried in the controller. You could never be sure what was going to show up with a given page.

I think there is a huge difference between working on gigantic corporate information systems and isolated green-field apps. Green-field apps are probably better suited to frameworks if you can build it and finish it and put it on the shelf. For really big systems with code that might survive 10 years or more, you have to think that your framework you started out with may look pretty dated after that period of time. As long as you have the time to fully adopt updates to your framework, then you'll be in pretty good shape. Otherwise you end up with the frankenstein apps that I've run across.

oscar nailed it perfectly. it's not about just using a "framework" for the sake of saying, "hey i use a framework". it's about a well architected application. consistent, scalable, and easy to maintain. IMO, a framework gives you that out of the box. but can you have that without a framework? absolutely. i should also point out that using a framework doesn't automatically mean you're writing "good" code. i've seen very bad code written inside of frameworks. hell, i've personally written very bad code inside of frameworks. it's still a conscious effort to develop good code either way.

@scott bennett: "However, I feel that my application architecture is just as organized and just as maintainable as it would be if used a framework."

then aren't you essentially... using a framework? just because it doesn't have its own web site or mailing list or session at cfunited doesn't mean it's not a framework :)

@mike rankin: "One of the reasons I don't care for many of the mainstream frameworks is that it really limits the people that can be dropped into a project quickly. So instead of being able to grab someone who has basic cf knowledge and is relatively sharp, I have to find someone with specific framework experience."

i'll respectfully disagree with that. i think using a community supported framework makes it easier to *potentially* find someone to come in and hit the ground running, as opposed to having to pay someone for a week of "ramp up" time. let's say you're using ColdFuseModelBox-ii. you could potentially bring someone in who can be productive on day 1. if you can't find someone who knows that particular framework... yes, you have to teach them how it works. but if you're *not* using a framework, don't you still have to teach them how you have things set up? the way i see it, you either break even there... or you find someone who already understand the architecture that you're using. but i don't see a downside.

I think Charlie is correct. One of the things that I have come across many times with clients is that developer x used his own framework. Thats great, no problems there, Im sure it made sense to him at the time. Problem is, like you said Scott, its "undocumented" so you run into the Beer Truck problem. If you get hit by a beer truck tomorrow, there is no documentation on your framework for developers to follow.

When using one of the mainstream frameworks, you get the benefit of it being documented and having tons of resources and help readily available to get ramped up.

This doesnt even take into account all of the often overlooked benefits to frameworks such as advanced caching, etc.

Can you build well architected applications without using one of the mainstream frameworks? Absolutely! But what are you leaving for other developers? I like to think that the developers that may come behind me someday, will have it much easier since there is plenty of documentation to get them up to speed wether they know ColdBox or not.

@Charlie - ColdFuseModelBox-ii ?? Really?? That is classic!

Russ/Scott Stroz,

Definitely have agree with you there, I have had many experiences working on code someone else wrote and having to spend a lot of time digging through their spaghetti code to find the line of code I need to change.

I *usually* do include a write up of the architecture I employ in any complicated applications I build from scratch. I also try to leave good comments in my code for other developers to follow. And if I am going to use it at my current full time job then entire architecture will have to be planned and documented thoroughly and approved by my boss and his boss before I can even start having my development team write the code.

At my current full time job, I work on an e-commerce application that has had many developers adding their own styles to the application over the last 10 years. I am in a position now where I can rebuild it, and was seriously considering model-glue as a framework, but if I can't figure out how to make it faster then I would have to buy 4-6 more servers to handle the sites traffic during the holiday season. My employer is much more concerned with the site being super fast then they are with how hard it is to maintain the application. They wouldn't mind new developers having to take a few days/weeks to figure out how the applications architecture, if it meant they could process more orders per hour.

It may be that I did something wrong in my Model-Glue code, which you can get from the download attached to his article, but I am pretty sure I followed the instruction exactly. I see a couple of you guys like Scott Stroz and Todd that are far more experienced in MG than I am. Are there tips on making it faster? Is it typical to have a seconds worth of overhead in a MG request?

You don't suck!

Frameworks don't suck!

There is a fine line between when you should and should NOT use a framework. Some people would use a framework for everything, and thats not right, frameworks are not for everything
and different frameworks are better suited to different applications

Dale,
Which framework do you feel is best suited to a high-traffic multi-server e-commerce application?

@Mike,

I have definitely not spent enough time or dug through the Model-Glue source code enough to know claim to know *completely* how it works, but I do understand the architecture and the principles behind it, and I have spent a good deal of time reading the documentation. I'm not going to implement anything until I am sure it will work for my application, but I have plenty of time to evaluate it so that's not really an issue. And If I need to hire another developer in the future, I would not be too concerned with whether they already knew my framework of choice or not. I would just pick the most talented candidate available to me at that time. If they already know it great, if not, it shouldn't take them too long to learn, or their not the right employee for me.

Scott,

Whoa - didn't mean the comment I just posted to come off as defensively as it did. I apologize.


For the first paragraph, I'd like to know what it is you're asking by the post - are we derailing (or am I missing your point) by focusing on MG performance?

In the interest of keeping things on the topic, I have edited the article by removing some side thoughts about things that don't really relate to what I intended to talk about in this post, and were founded only on my inexperienced first impressions of the Model-Glue tutorial application.

I really do like Model-Glue, I am sure after I get more familiar with all of it's intricacies, I will be blogging more about it. Perhaps I will write a blog entry about how the ColdFusion debugger can make it appear slower than it really is =)

@Mark,
LOL! That's pretty much what I say every time I inherit an application. And I doubt that will change even if I start using a framework and then start having to edit someone else's framework code.

Now that is hilarious. lol

I agree with Oscar.

I like knowing that people who work on my projects know the technologies I use inside and out. I've learned through experiance that I can tell someone in very explicit language where to find code or what I'm going to do when we both use the same framework.

Furthermore, I am always suspect of a developer who says they "know" OO. I teach classes on MG and CS and one of the first questions I always ask is who uses OO. Most people raise their hands. But, but the end of the first presentation on CFCs usually there are a of of surprised people in the class. By the end of the week these same people are saying they had no idea how deep some of this stuff goes.

In my opinion OO isn't so much something you know as much as a way of looking at software development. So, if someone is using a framework I respect and being productive in it I have a good feeling that they really know OO. If not, then I think twice.

All I'm really trying to say is that there's a subtle difference between writing CFCs and Object Oriented Development.

What's the difference exactly between what is a framework and what is architecture? The reason I ask is that it seems like quite a few folks are using their own "framework" but maybe that's not the right term?

For me, while frameworks are about maintenance, and having to write less documentation, really, its about having > 300 testers at hand on a given piece of code.

There is just no way you can write a piece of code, on your own or as a team, that is more thoroughly tested than a community project.

@Mark,
It is a common argument in favor of using community frameworks to say that if you use a popular framework you have the benefit of having 300+ testers. In my opinion this is a flawed argument. Why? because those 300+ testers are only testing a small fraction of your application; they are only testing things that are inherent to the framework and not to your application. You could have 3000 testers for your framework but your application can still fail miserably because the business logic is wrong or you have an incorrect link somewhere. The only assurance that those 300+ testers can give you is that all the extra features and overhead the framework provides works as intended; but the reality is that you may not be using all those extra features, so the benefit of those hundreds of testers doesn't really mean much at the end.

Now, I'm not against frameworks either, I just think that usually the arguments used in favor of using a community framework are not always correct.

@Oscar,
I have to respectfully disagree with your disagreement.

I know from personal experience, the amount of testing that my users have done for Transfer has been invaluable, and quite frankly, took it far and beyond where I have ever used the framework.

While not all the developers test the 'outer edges' of the framework, many do, and in * varied * ways. (It's always interesting to see how people actually do use Transfer).

Everyone uses a framework. Only question is whether it's community or in-house. Benefits of community framework are that it will be easier to get others up to speed (more documentation), more people know it already, and there is less likelihood of you coming across bugs in the framework as it is well tested.

The downside of a community framework is that they are designed to solve a wide class of use cases, so they are less likely to be an optimal solution for any given use cases - especially those that are substantially outside the norm.

As others have mentioned, the quality of an app is pretty much orthogonal to whether it uses a community framework. However, because of the pressures on open source (nobody wants to release lousy code, and if they do, nobody uses it), the average quality of successful community frameworks is much higher than the average quality of in-house frameworks. It's the old problem of everyone believing that they are above average in their skills. unfortunately only half of them are right :-)

@John,

You make some good points, and what I would typically do in a larger application, is look for ways to handle events in a more generic fashion so my code didn't have to have 800+ case statements. If that means it would be best if I used with Mode-Glue/Mach-II or build my own lighter weight event controller that reads an XML configuration file when the application initializes and uses implicit invocation or whatever, then I would do whatever my application needed. And as I noted before, on a large application like that, I think a community supported framework would be a good way to go, because there are bound to be a lot of developers involved in such an application over time.

While I think *I* could maintain my code very easily no matter how I organized the it, a large application demands that I (as the original architect of the application) need make decisions that ensure everyone else that *ever* works on the application will be able to maintain it as well. The decision is then to re-invent the wheel and create a well documented framework, or use one of the community based frameworks that have already done that for you.

But seriously, how many applications do most developers work on that are so huge that these issues would come up? What I am saying is that you have to pick what is best for you application. If I am building an e-commerce site, it doesn't have that many events. There is a very finite amount of functionality that will ever be needed on that application and I can easily maintain it using my architecture. I will create a few controller CFCs to handle events in different sections of my application to keep my case statement small, and that works out nicely in most situations, and the code is still organized and clean. If I am making an application that is just going to be what it is and it will never be built upon to grow into a giant application that runs every aspect of a giant company, then there is not point in having any extra overhead to prepare for that possibility.

My personal opinion is that, in most normal sized applications, it would be just as easy to maintain a few controllers with case statements as it would be to maintain the XML files that are in many of the community frameworks. And if done right, the case statement will perform a tad faster (in case performance is something that is more important to your application than being able to find a new developer who can be familiar with its architecture in 10 minutes or less).

BUT... all that aside, my main point of this blog entry is more about the fact that even though I personally have never had the opportunity to employ a community based framework in a production application, that doesn't mean I am any more or less valuable then someone who has used them. As many people have noted already you can write crappy code with or without a community supported framework. My example is just to demonstrate that some of us "non community framework" developers also know how to organize code in a maintainable fashion. And while we may not have experience in your favorite framework, we can bring a lot of other more valuable expertise to the table that may makeup for the fact that it might take us a little more time to get used to your sites architecture. Some of us might even be fast enough that we could learn the community framework, and still build the application faster the some developers that already are familiar with the framework, but may be a little slower at programming in general.

Frameworks are just another buzzword, like "Internet," or "Electricity," and "Horseless Carriage."