Why Frameworks Suck
Development frameworks are supposed to be our friends. Instead, they often just get in the way. Frameworks suck.
What’s a framework?
A framework is a set of libraries that attempt to make certain tasks easier. For example, instead of parsing an XML file character by character each and every time you need to work with XML, you might have a set of functions to help you do that.
$elements = $XML->parse();
Now imagine that kind of simplicity with all your other common tasks like sending e-mails, creating and validating forms, or managing a database. This is a framework.
Where do frameworks come from?
“I like to share”
Frameworks are made by developers just like you and me. For the most part, once you’ve been developing for any length of time, you simply begin to build a collection of functions and classes that you use on a regular basis. Some even take that extra step to unify the API for the framework; remove duplicate code, clean up naming convention, make it modular.
Then, with such kindness, they share it with the world! Do a search for “PHP Framework” on SourceForge and you’ll instantly catch a glimpse of how expansive the framework space is.
Framework in mind
Some developers actually set out to build a framework as a project unto itself. I’d imagine this to be a little trickier as you might not have thought through enough of the use cases to solve the problems that the framework is designed to solve. Like, building an e-mail class to e-mail people but not supporting encoded headers for internationalization, just because you didn’t think about it.
Brother from another mother
You’ve programmed in Java all your life and now find yourself in PHP land. What are you to do? Make a framework, of course! One that mimics all the features of your favourite language. A mimic framework seems to make sense but in actuality, it really only makes sense to other programmers who used to use Java and are now looking for its PHP counterpart. This is a fairly common approach and one I’ve fallen into from time to time. For example, I’ve made echo functions in just about every other language I’ve used.
The concept makes sense on the surface. You’re in your comfort zone. You get to use the methods and properties that you know and love. Nothing slows you down. But you slow down any developer who works on the project after you. They not only have to know the language for the project, they also have to learn the framework or worse, learn the language that the framework is attempting to mimic.
Learning a Framework is like learning a language
And this is ultimately why I think frameworks suck. Learning a framework is really like learning a language. You want to save to a file; here is what you need to type to accomplish that. What you type could be native to the language or it could be part of a framework. But once you’re using it, it’d be a lot of work to take it out. You certainly can’t replace a framework once you’ve started using it.
And what happens when something goes wrong? A framework adds a level (or more) of abstraction to the overall rendering process. As a result, when something goes wrong, more work goes into understanding how the framework ticks than solving the problem (assuming you didn’t build the framework yourself and would already have intimate knowledge of it).
Is it really that bad?
In actuality, no. Having a framework does make your life easier but know it inside and out. That’s something that may only come from developing your own.
To give you a personal example, to try and save time on a project, I decided to use Smarty. One particular feature relied on a certain level of error reporting. No biggie except the framework already in place was set up to e-mail us whenever any PHP error occurred. Suddenly, we were receiving e-mails on each page load.
It’s situations like these that you can never predict or plan for. When they happen, just hope that someone else has run into something similar and documented it. Otherwise, prepare to spend some time testing.
The exception (there’s always one)
If ever there was an exception to the rule, it’s Ruby on Rails. It has the large benefit of being the de facto web application framework for the Ruby language. Ruby was rarely mentioned of before Rails made its appearance. Now, anyone learning Ruby for the first time is likely learning the Ruby on Rails way. As such, learning the framework is learning the language. They’re practically one and the same.
That’s not to say there aren’t or will never be other frameworks for Ruby. There is and there will be.
What do you do?
So, did you build your own or use something already out there?