D.Ross.Blog: Frameworks, Methodologies
Let's get this conversation out in the open.
Let's take some quotes from my infamous comments...
"That's my point, I am sure it is a good methodology, and I am all for improving our standards of coding to make ColdFusion is the solution for the web applications.
However, no methodology should sacrifice core values of performance and usability.
I understand for example, how it helps to have a common methodology for a team.
I am not here because I like slamming methodologies, I just want to make sure we are choosing methodologies for the right reason.
Because no matter how a methodology improves our coding standards/skills, it doesn't matter as long as it's coded to be the most efficient in performance and usable to the clients."
My point is that several-fold:
1. We should not just jump to a framework because everyone else does, or because it's a trend or fad. It must be because it fulfills the needs we have as a team/coder and because it delivers on our core values.
2. I don't care if it's the most elegant framework in the world, but if it takes away from the core values, then it's really not yet a good framework.
Here are my core values, and I hope they are similar to yours:
1. Performance and Scalibility: As my web apps get used by more and more people, I have to make sure that the web app is built for handling that, by using the most EFFICIENT/FASTEST LOADING ways of delivering functionality/content or whatever.
2. Url Usability: It sounds trivial, but it's actually a very important subtle thing. People like to be able to bookmark, or understand what page they are at. The old fusebox method of having all apps be on one page with different url variables, just doesn't cut it. Especially in the day of trying to do search engine optimization.
I do know it can do the seo friendly urls, but it should be on seperate pages. Which can be fusebox if you like that just includes the fusebox code. But we need to go a products page or a shopping cart page. There needs to be a visible difference in the address bar between pages.
3. The framework should be built to be easy to understand for people who don't even use that framework.
Point-in-case, at work we have several fusebox apps, that we don't even bother trying to fix because it's so convoluted trying to find where the actual code is and what not.
Now, I do approve of frameworks, as long as they are done right.
Of course it is much better than going blindly with no standards or no framework....
But we have to evaluate what is a good framework and what is a bad framework.
There are plenty of innovations that fusebox and other frameworks have brough to the cf world, that I like.
Like the idea of wireframing your apps, I still want to play with that as a great way of planning out your app logic.
I have not yet played with mach-ii. I am honestly a late adapter, probably always will be.
And maybe I still think that a good web app, is 1-3 pages with 5-10 cfincludes...
And because my code is commented, indented, planned, easy to read and understand, then I don't have to worry about dying, and having someone try to figure out what the heck my code is trying to do.
Unless coldfusion has changed so much that the speed differences are a lot different than they used to be, then I'll be glad to change my mind.
As long as the reuse method is the most EFFICIENT/RELIABLE way.
And as a nice as cfc's are, they are not it, nor are cfmodules or cffunctions or cfscripts.
CFINCLUDES are still the fastest gun in the REUSE West...