You might not need a CSS framework

CSS frameworks have been around for a while and they have gotten extremely popular in the front-end development scene. These frameworks provide snippets of code you can just copy and paste in your website to craft the whole layout and UI.

You have already probably read a lot of articles about how they might be good for your projects, but here I would like to do the opposite: to highlight some of the drawbacks they might bring to your websites or applications, and how you can avoid or mitigate them.


When I ask people why they are using a particular framework, their answer usually falls into one (or more) of these categories:

  1. Speed: Most people believe it will make development faster. And this may be true in the initial stages of a project. But this gain may be followed at the expense of technical debt – we will see how the debt is produced – that will need to be paid later on, with interest.
  2. Best practice: Some people believe it is a best practice to use a framework, especially those just beginning front-end development. This is reinforced by the avalanche of articles and by the inclusion of frameworks in bootcamp curriculums or in job descriptions that mention them.
  3. Design: A lot of developers just want to release something and they don’t have a designer available for their project. CSS frameworks provide a basic design developers can use. While this is useful, the consequence is that your site or app ends up looking like every other recent site on the Internet –but whether that impacts your project is up to you to decide.

Technical debt

Regardless of the reasons for using a framework, frameworks might introduce technical debt in your project. Sometimes it can make sense to have this technical debt, for instance if you need to launch something as soon as possible or if you’re building a prototype whose code will be discarded later.

However, for big projects like an ongoing website or application, this technical debt can potentially become unmanageable and hinder development. Let’s see why this happens.

Unsemantic HTML code

This is not a problem of frameworks per se, but I have seen it happen a lot in the most popular ones.

For instance, maybe you’re reading documentation for styling buttons: You might find a code snippet that tells you to use a CSS class for disabled buttons instead of adding the disabled attribute to the <button> tag itself.

There are abundant examples of <div> or <span> where a more semantic tag would be appropriate. And let’s not talk about the <div> inside a <div>, inside a <div>

Over-specific CSS selectors

Again, this is not a problem intrinsic to frameworks, but something we can observe in the most popular ones: there is a tendency to use very specific selectors to create the CSS rules. For instance:

.table-responsive > .table-bordered > thead > tr > th:first-child

What happens if you need to override some of the properties of your <th>? Then you need to create an even more specific selector! You can’t just get away with creating a generic rule like:

th.important-heading { color: #000; }

Instead you would need to set up a rule like this:

.table-responsive > .table-bordered > thead > tr > th:first-child.important-heading {
  color: #000;

What happens in the wild is that nobody wants to write that kind of code. We soon start to see these kind of rules popping up:

th.important-heading { color: #000; !important }

…which only makes the problem worse!

Rules you don’t need

If you include a whole framework instead of just the bits you really need you will have CSS rules you are not actually using.

Of course you can mitigate this with the aid of a post-processing tool to remove unused rules, but the moment you begin to add or remove classes dynamically with JavaScript, you’ll never be 100% sure that you will not need that code.

Unused CSS not only makes your files bigger, which can be a problem for mobile devices that are connected to a cellular network rather than wi-fi, but they make your codebase larger too, and thus harder to maintain.

Owning your opinions and decisions

All frameworks are opinionated. This is not an issue if you don’t have a strong opinion or if yours is the same as the frameworks.

But sometimes you do have strong opinions. For instance, here’s the HTML one framework proposes to create some coloured text labels:

<span class=“label label-warning”>Out of stock</span>

I find these classes redundant, since I like to use only the classes I deem necessary. If that were my code, I would probably only have a class label-warning.

And what if you are a fan of a specific CSS methodology (like “Block, Element, Modifier”) your framework doesn’t use?

Alternatives to frameworks

Write your own HTML and CSS. If you don’t like the markup a framework produces, you should write your own. If the CSS rules a framework provides makes you work inefficiently, you should craft your own rules.

If you need a grid, you can use Flexbox today, which makes crafting a layout much less painful than using floating divs. If you are not familiar with Flexbox, take a look at this MDN guide. If you are curious about how the code might look, here’s an implementation of the Holy Grail layout I did using Flexbox.

In the future we will have Grid! This will make creating layouts a breeze, and you won’t feel the urge to use an existing grid framework ever again. Here’s another implementation of the Holy Grail layout, this time using Grid.

(Note: To see the actual result running in your browser, try Firefox Nightly or the latest Firefox Developer Edition browser —it just works. To view these examples in any other Firefox release, you’ll need to flip the flag. Go to about:config in the browser to enable layout.css.grid.enabled functionality.)

If you just need a UI widget, like a custom dropdown menu, and you don’t want to code it from scratch, you can always grab that bit—instead of the whole framework—or use a 3rd-party component that has no external dependencies.

If you need a design you can use, one reasonable way to use these frameworks would be to grab the Sass or Less sources instead of the generated CSS files. If you do this, you can grab the mixins and create your own selectors, which will allow you to have your own markup. But keep in mind that your site will look exactly like loads of other sites as well!

If you need a way to standardise the UI creation in your project, so people know which code to use and how to add new interface elements, what you are looking for is a style guide (in short, your very own custom framework). You should have one for big projects!

In summary

CSS frameworks may have advantages, but they also have drawbacks that are often overlooked. Be aware of those and also know the tools and APIs you have at your disposal for creating the CSS and markup of your sites and apps.


View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)
Tagged on: , ,

5 thoughts on “You might not need a CSS framework

  1. Jesús Perales

    simplemente “Evite el exceso”

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. John Bilicki

    Finally someone actually using their brain! When you walk in to another company or previously started project 99.9% of the time it’s not if they lamed out and used a framework but it’s which framework they lamed out and used. Part of the blame is when people new to these technologies walk in other people come along and bash frameworks over their heads instead of teaching them actual real code. How many WordPress websites have 280KB of jQuery? Even with one copy that is more code that sits there and does nothing at all while I’m able to load everything including administrative JavaScript, CSS and XHTML5 in less than 70KB of a single copy.

    Another false argument for frameworks is compatibility. There is this spiffy thing in JavaScript called object detection. Plus for those complaining about CSS compatibility it’s not hard. My platform appends the correct prefixes if applicable without any reference to a single useragent so I only ever code W3C except for very specific pieces of vendor DOM that aren’t part of any standard.

    Then look at frameworks and what they do. “clearfix”? Really? Just use .clear for goodness sakes! Plus if you need to clear so often then it’s time to look at why you need to clear stuff! “pullleft”….Bootstrap is exactly what it’s initials are; it’s a framework developed by server guys who don’t get client side development.

    For the “we don’t have enough time” you TELL your bosses it’s going to take that much time and if they don’t like it then either they need to allot you more time or avoid doing that given project outright. What is the point of having technical expertise if you don’t force people to acknowledge it?

    There is doing things the right way and there is doing things the expensive way and there is nothing expensive about getting things done the right way.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  3. Brandon Zell

    True, if you look at the global stats, border-radius does not have 90%, but it supports back to IE 9 with no bugs.

    Flexbox is buggy, even in IE 11 which isn’t ancient. I would LOVE to start using Flexbox, but with the current browser support I’m not comfortable making the switch.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  4. Belén Albeza

    Hi Brandon,

    From the same link you posted you can see support is > 94%. As a comparison, border-radius doesn’t reach 90%.

    So yes, I’d say you can (should) use Flexbox today –unless you are forced to support ancient versions of Internet Explorer.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

Leave a Reply