Using A Framework
by Dave Tufts - May 13, 2008 / 3:08pm View more articles
Will Bond recently shared an article, curtly titled Why Frameworks Suck. Though the article is a year old it was recently promoted on Hacker News.
The author, like an old Beastie Boys song, uses every analogy in the book to dismiss frameworks.
Frameworks, to the author, are like an all-in-one woodworking tool…
I like a big set of tools available to call upon at need, I like to have a favorite hammer and a favorite saw and know the tricks for making them both fit on my belt without running into my legs when I am working on something. Framework people like the 5-in-1 lathe-press-drill-saw-grinder and figuring out the tricks to fit the piece of wood they are working on into the machine. When you have a framework everything will be lathe-press-drill-saw-grinded into submission, and you better read the manual otherwise the machine won’t even turn on.
Frameworks are like organized professional sports…
If building an application with libraries is playing football with your buddies, building an application on a large framework is playing football in the NFL. […] it’s just not fun anymore.
Frameworks are inseparable dinnerware…
Frameworks hurt sharing. I’d really like to give you this fork Jimmy, but you’re gonna need a knife and plate to use it.
Frameworks conspire against creativity and individual problem solving…
Frameworks suck because they make you fit your project to the toolset rather than the toolset to the project, and frameworks suck because they take the fun out of programming, long live the library.
While the arguments are valid and refreshing to hear, they are one-sided. After reading the article, I found myself agreeing with many of the follow-up comments at Hacker News. Most of all, it's not the concept of frameworks that stinks, it's other people's frameworks. Your own, custom written framework will never stink—at least, it won't stink for you.
For our first 8 years, 1997–2005, iMarc used libraries and shunned frameworks. As the author points out, there are many positives to this approach. All components—database library, session library, form validation library—are independent and self-contained. Our developers used these libraries to speed up common tasks, but each website was a new frontier.
Using analogies from the original article, at some point there's a preferred middle ground between the freedom and independence of working with programming libraries and the shackles of using someone else's monolithic framework.
In woodworking, the carpenter can still use his favorite tools while utilizing jigs and implementing a well-defined process. In backyard football, it's actually more fun when there are some agreed-upon rules. With dinnerware, most people eventually succumb to matched utensils and place settings. In each instance, it's the individual finding there own way and implementing a framework customized for them.
It's a logical step to evolve one's library of tools into a custom framework. The framework will be based on your needs. It will be the right size for you. It will impose restrictions—but everything will be based on decisions you make.
A collection of libraries solves coding problems—repetition or complication of code. A framework solves process problems—repetition or complication of process.
Hiring: We’re hiring a
RSS
8 Comments
That said, I tried to make repetitive tasks more automatic, and kept more complex tasks as something that needed to be filled in as you develop.
I did find that while using my framework, I was still doing a lot of repetitive stuff, but it was different than the stuff I used to do. It was essentially a whole new layer of repetitive tasks.
Instead of furthering the specifics of the code and automating those processes, I just left it as it is. What is repetitive to me may not be how others would use the code, and that's something I needed to build in as well. Also, sometimes things are just going to be repetitive, and it isn't a bad thing. I suppose the challenge is knowing which is which.
I believe in frameworks, but I believe more in knowing what the point of the framework is, what it looks to accomplish and make sure that I'm using it for its correct purposes. The "be-all-end-all" solutions tend to over-simplify or super-automate processes to the point where I feel like things are out of my control. Know what you're using, how it works and what it's doing and everything comes out fine.
All of the frameworks whose design patterns I liked, wanted to force me to use XML config files and machine local command line scripts to produce "builds" of my web application to then send to the development/testing server —or worse yet, assumed that my local machine would be my dev/test box...
I've run against that wall too many times and have finally given in to creating (collecting) my own framework... a library of reusable stuff I'm accumulating into an API.
You can check it out at the link below if you like, but I'm not lookin' for users :-)
http://code.google.com/p/elswebappkit/
Back to the point... a framework is your scaffolding and toolset. A builder can either buy a pre-made package of scaffolding and learn to work with it, or he can build or collect the items that help him work and they become his own framework. Even if you throw all your stuff away and buy or build all new things for the next project, you're still working with tools and helpers to get you going.
Frameworks are simply what helps you get the job done, they're not limited to projects like CakePHP and Rails.
Then the cool CF table called me over and what was once the "cool table" is now the place in which I eat my lunch. Shunning any tool in the industry is usually based on lack of knowledge, not lack of functionality.
Really the whole topic is heavily affected by the context of development. The various types of frameworks, libraries and so forth have their time and place. Additionally, I do think semantics are important here, as in almost all other situations in human interaction.
I'll try to outline how I view the distinction below, however I know these are not the most rock solid analogies.
Frameworks are collections of code that create literally a frame for you to work in. Liken it to the framing and architecture of a building. You get to choose what each room will be used for, pick paint colors, etc. Frameworks tend to break down into two different flavors, rigid and flexible. Rigid frameworks tend to come bundled with a lot of the plumbing and you can't change it. Flexible frameworks tend to allows certain components to be swapped out.
Libraries are collections of code that provide functionality and recommended ways to combine them together. You could probably think of them as a big stack of lumber and a set of blueprints. You can construct the building as the blueprints recommend, or go your own way. Obviously if you don’t know what you are doing, this is gonna make it harder to start than a framework. For an experienced developer it can be easier to get exactly what you need/want without having to do the nitty-gritty of chopping down the trees and milling your own planks.
In either situation I think the biggest failure of almost every web framework/library I have ever learned or read about is that they don't communicate their specific goals and benefits. Almost every one makes terribly broad statements like “Foo Framework allows developers to rapidly develop highly functional websites without getting in the way.” This doesn’t help any developer, ever. It is analogous to having a marketing campaign that just says, “Hey, we make the best foobar available.”
One of the other prominent issues I seem with the framework evangelists is that they believe that their framework is applicable to every situation. There is such a wide variety of development out there that it is not possible to create a framework that works in every situation. Rails is overkill in some situations and too restrictive in others. The Zend Framework is insane for a small project, but better for projects where you might traditionally see Java.
So, in the end, I think everyone could benefit from better framework information and being sure to do their research before picking a solution. Obviously picking a solution with good documentation and an active community is desirable.
Oh yeah, and not everything is a framework. The three classes some developer created for their projects is not a framework.
I'm arguing against a large-scale framework in iMarc's particular situation. We build and maintain many sites and it seems beneficial to use a home-grown framework that we are intimate with and can customize instantly. For a freelancer or small company - or a company that maintains only a few webapps - finding a well established, large-scale mature framework makes more sense...if the you don't find yourself changing your application to fit the framework.
Ruby on Rails was originally a home grown framework built to run 37Signals collaborative web apps. As the name implies, the underlying language is Ruby.
Django was originally built to power news websites. Like Ruby on Rails, it's grown to encompass much more. Django uses Python.
If you're used to PHP, there are more choices:
The Zend Framework seems to do everything. It's focus on enterprise level apps seems too large and bloated for me.
CakePHP and Symfony seem more community focused.
Struts is a Java-based framework that a friend of mine is really into. It's supposedly easy to package, distribute, and deploy your web-app.
If I were picking a framework, I'd visit each site and read the documentation. Is it well written? Is there general, high-level, conceptual documentation? Is there API documentation? If you're jumping into someone else's framework, you don't want to be reading code. One of the most important decision factors is how well it's documented.
See how I just went all John McCain on you there...