I differentiate two framework types:

1. General all–purpose frameworks
2. Frameworks for a specific site/project

The ones I have a problem with are the all-purpose ones, and I’ll go into more detail on them now.

All–Purpose Frameworks, Gaaahh!

First of all, I acknowledge that frameworks speed up the process of coding a Web site, that is their upside and I’m cool with that, it’s a tempting feature. On the other side, I feel like they are bringing style sheets to the masses if you know what I mean. All of a sudden everyone’s a master of hand-coding Web sites. Along with that, each and every framework I have taken a look at implies a certain aesthetic along with it. Also, the biggest drawback for me is that they require you to write markup a certain way, or at least to some extent. Even if we’re not talking about code, but the way it structures elements, distributes the layout, etc. After this, one common thing all of the frameworks share is the bloat—the unnecessary and unused code I just can’t stand. I have learned to write CSS by the “the less code the better” method. Always clean up the elements you don’t use. Assign meaningful class names and IDs and avoid adding too many, but add as many as it is needed. Use descendent selectors properly and don’t abuse them. Write meaningful markup that can be easily manipulated if taken out of context. Don’t jam extra elements into the markup just to achieve an effect—change the effect instead (if you can). The list goes on and frameworks generally tend to not be in sync with these things I highly appreciate in the way HTML and CSS are written.

One place where I see an application for all-purpose CSS frameworks is rapid prototyping and mockups in xHTML/CSS. I can go with that.

Site-Specific Frameworks

OK, now this is something I can work with. I am all for developing a set (or multiple sets) of rules and conventions when building a Web site, especially if the site is fairly large. You can only benefit from that kind of standardization.

1. It makes maintenance easier
2. People who are brought into the project later on are able to get to know the code fast (if it’s well documented)
3. The code looks unified overall
4. Further development is faster

So while it maybe makes little sense to put in some extra hours into developing a site-specific framework and document it properly in the early stages of the project, trust me—it will pay off in the long run.

This all coming from a guy that has built Uni-Form, huh. Whaddaya know…

Another take on the subject from Natalie Downe (via Jeff Croft) that separates frameworks from libraries. I guess what I was talking about was that I can work with libraries, but don’t dig frameworks so much. Great read.