Life without a BS Foundation

On April 29th 2014, I presented on a topic titled “Bootstrap and Foundation are not your crutch”. The topic was described as:
 “Although frameworks like Twitter BootStrap and Zurb Foundation are great starting points, examples of good practices, and foundations from which you can easily create prototypes, heavy reliance on these frameworks can create pitfalls that will be felt as the project expands. CSS bloat, lack of knowledge for the underlying framework code, and compromising best practices are examples of mistakes that can happen due to the overuse of these frameworks. The object of this presentation is not only to point out the pitfalls of using these frameworks, but also to provide guidelines on how to take advantage of them.”
And the video of the above presentation is:

(I recommend watching it as I will be referencing some portions of it in this blog post)

However, after some post-presentation hallway chats with some attendees, I have become aware that my message was not well received. The message that the best solution to using CSS frameworks is to NOT use them, was a very hard pill for some to swallow. Although I haven’t changed my opinion on this subject, too many experiences with bloated CSS prevent me to do so, I do empathize with the plight of some. I was given a few scenarios that I will go through one by one and see if we can some to a happy medium conclusion.
Do not panic. You don’t have to go and erase all your CSS code and start from scratch. Like all technical decisions, there are some give and take. It is up to you and your team to evaluate whether the risks that come with implementing a CSS framework is acceptable.  However, what I would recommend, regardless of which option you choose is to follow these guideline:
Before we go through the scenarios, let’s put some goals for us to achieve and also give each goal rating for a final score:
  • Be able to implement the design, layout, and pages to achieve the final product, prototype, etc… (rating: 5)
  • Create the necessary styles and be able to find them easily and maintain them in a timely manner (rating: 3)
  • Avoid CSS bloat and be able to create a performant and extensible CSS base (rating: 2)
I don’t think these goals are radical and I think they should be on the forefront of every project. That being said, let’s look at the scenarios.

“I don’t have the CSS expertise to write my own framework”

Let’s set aside the fallacy that writing a CSS framework requires CSS expertise (before any of these framework were available, we were all writing our own “framework”) and talk about the CSS level needed to complete a project (not build a framework). I will repeat the wisdom of Scott Kellum “CSS isn’t voodoo, it’s a simple and straightforward language where you declare an element has a style and it happens.” The level of CSS knowledge needed to begin is not much. The other questions that must be asked is:

  • Is the framework needed as a starting point?
  • Do you bring the entire framework into the project or do you just bring the necessary modules?
  • What is knowledge level on pre-processors like Sass CSS or LESS?
  • Will you be modifying the pre-compiled code or the final compiled CSS?
  • How much will you be relying on the framework? Do you want to be able to upgrade if new versions becomes available?

So you have downloaded the desired framework and you have started using it. Everything is running smoothly and project is coming along quite nicely. At this point, you have probably built a custom CSS that sits on top of the framework, possibly riddled with “!important” flags (by the way, every time an “!important” flag is used, a CSS fairy loses their wings), and the project is being built according to plan. Then issues arise that may require you to move farther up the CSS chain and actually look into the framework code. This is where the reasoning behind using the framework, the CSS expertise level, will be the reason that will probably bite you in the ass. Where a small issue should’ve been fixed quickly, it has turned into an effort that will take longer than needed.

Goals achieved:
  • We were able to implement the design and build the final product – score 5
  • Not easily find and maintain the code – score 1.5
  • Not much effort in avoiding bloat – score 0


“I am just building a prototype”

If you are just building a prototype and you will be using the CSS framework, Bootstrap or Foundation or Inuit, without any customization; then you are in rather good shape. This is one scenario a CSS framework will become very useful, to get ideas in front of consumers and to get feedback. However, this is where the utopian marriage between a CSS framework and a deliverable product ends.

Let us theorize that the happy path of the prototype was built brilliantly (no customization was needed on the CSS) and ideas were communicated and money/investment/green light was bestowed upon all involved. Now the next step of the project is to roll your sleeves up and go beyond the prototype and build the product, which will have a customized design and will involve writing the necessary styles and CSS for the product. What will be the approach? Keep the CSS framework and build on top of it? Or build your own CSS framework? Will you follow the “I don’t have the CSS expertise to write my own framework” approach or will you power through the process and build it? if the code is built on top of the framework, this is where the frameworks will falter. The extension is where it will create some CSS bloat and undesirable results.

Goals achieved:

     Prototype implementation:

  • Able to implement the design, out of the box design – score 5
  • Code maintenance is part of the framework maintenance – score 2
  • No bloat – score 2

Future implementation:

  • Implementation of the design on top of the framework – score 4
  • Code maintenance questionable – score 1.5
  • Extra bloat – score 1

Prototype implementation:

Future implementation:

“I have already invested a lot of time in <insert CSS framework here> integration”

OK, so you are already chained and committed heavily to your chosen framework. Here are some of the issues that you may confront:

  • Semantic HTML & CSS – frameworks do not write very semantic classes and most names are general purpose names
  • Performance implications – is there any CSS bloat?
  • OOCSS implementation – Is there any Object Oriented CSS implementation?
  • File organization – What is your file organization?
  • Coding convention – Is there a set coding or naming convention?

If you have hit any of these issues, it is a business decision whether to stay committed to the chosen framework or not. The problem is that if the above issues have not reared their ugly heads, they slowly will creep up and eventually will surface either one at a time or all at once.

Goals achieved:

I am not sure as this is a decision that is up to the developer on how much tolerance they have. But since I am grading, here it is:

  • Able to implement the design – score 5
  • Code maintenance – score 0
  • Bloated CSS, yes – score 0


What does all these scores mean?

  • 8=< score =< 10:  You are in good shape and should be high fiving all your teammates
  • 6.5 =< score < 8: There may be danger around the corner like maintenance issues, file organization, or CSS bloat, tread carefully
  • score < 6: Time to evaluate your code and come up with a solution



CSS frameworks are filling a void that was among CSS development, there needed to be structure and organization to the CSS code. Frameworks created that, however they cannot be all things to everybody and by trying to be that, is where they fail. If the need is to use a framework, I would highly recommend:

  • Use it bit by bit. Select the modules that you need and don’t bring in the entire framework. Grid system is one I always use.
  • Learn from it.. View the CSS code and learn from it.
  • Use a pre-processor –> Sass CSS (because among all pre-processors, there is no substitute)

Last but not least, these popular frameworks are very opinionated. I don’t think that is a flaw but why not insert your own opinion? Why not establish your own mini framework? One that you are familiar with and know which portions to use as you are going from one project to another. Just an idea.