“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

Score:

6.5

“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

Score:

Prototype implementation:
9

Future implementation:
6.5

“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

Score:

5

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

Conclusion

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.