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.


About Belén Albeza

Belén is an engineer and game developer working at Mozilla Developer Relations. She cares about web standards, high-quality code, accesibility and game development.

More articles by Belén Albeza…


  1. Brandon Zell

    “you can use Flexbox today”

    I’m not sure browser support is good enough to use flexbox for everything:

    April 21st, 2016 at 12:07

    1. 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.

      April 21st, 2016 at 12:17

      1. 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.

        April 21st, 2016 at 13:12

        1. Philippe Lhoste

          I used Flexbox in our application (SPA), to lay out a header, two side bars (or less, depend on page) and a central content (among other things): neither trivial nor overly complex. Displays fine in IE 10 / 11.

          You can reject Flexbox until non-buggy implementations are widespread. Or start using it now, testing your usage to ensure it is fine everywhere…

          Well, like any CSS feature, I suppose.

          April 22nd, 2016 at 04:09

          1. Alex Mandl

            That 6.1% usage of IE is mainly due to the higher use in Japan.
            If you design a website for a local Supermarket chain or anything that sells goods only inland, don’t be afraid of flexbox.

            April 23rd, 2016 at 06:21

        2. Chris

          I think that the best practice thing to do in cases like this, if time is available of course, is to go right ahead and use flexbox. You can use feature detection such as Modernizr, then create graceful fallbacks to floats, if we are talking about layout for example.

          You can even detect i.e. 11 specifically using browser detection (not always best practice, but sometimes necessary).

          Putting off the use of features instead of embracing the new power and flexibility (pun intended) seems counterintuitive in such a quickly evolving and ever-improving industry.

          The ultimate goal is to have projects that are built in the most future-proof, modern way, that progressively enhance and gracefully degrade.

          All of this is great, but we all have those projects that are exceptions where time is precious or budget is non-existant, but as front-end developers it is literally our job to push the boundaries of browser capability and embrace future technologies when they become available.

          That’s my thoughts anyway!

          April 22nd, 2016 at 12:23

        3. JAson Witt

          Also, if border-radius doesn’t work you don’t get rounded corners. If Flexbox doesn’t work you break the whole site.

          April 23rd, 2016 at 07:04

    2. changke

      April 23rd, 2016 at 13:36

  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.

    April 21st, 2016 at 14:59

    1. Dave Woodall

      Belén, great post! I read something similar about Single Page apps that convinced me that they are their own skill set and not a requirement for me, a Rails developer. [1]

      John, I enjoyed your comments as well and the two of you have given me the confidence to go with my gut and just code, since I know how to code well enough to not want to lean on a framework because of the many points you both laid out.

      upward and onward!


      April 27th, 2016 at 13:41

  3. Jesús Perales

    simplemente “Evite el exceso”

    April 21st, 2016 at 17:09

  4. Jason Knight

    I’ve been saying this with a bit more vehemence since the day people started using frameworks in the first place! They are at BEST nube predating scam artist BS that can be thrown around as a sick buzzword to impress the suits who think they can get sound technical advice from the pages of Forbes. (which is akin to getting financial advice from Popular Electronics)

    At WORST they are a way for people who don’t know enough HTML or CSS to be building websites in the first damned place to delude themselves into thinking they can, all whilst flipping a giant middle finger at users with accessibility needs.

    Hence my own slightly more insulting article on the topic, that questions the mental fortitude of those who use idiocy like bootcrap, and the testicular fortitude of those who promote it’s use!

    Anyone who THINKS that the framework is making their life easier or better, probably doesn’t know enough about HTML or CSS to even be opening their trap on the damned subject!!!

    April 21st, 2016 at 18:19

    1. David

      Just try to work your way thru a project with some juniors and limited budget. Thats what frameworks are made for in my opinion.

      April 30th, 2016 at 22:56

  5. Stefan

    Imo best practise is using a SASS or LESS version of the framework and start with the core. Add the additional things only when you need them. I don’t agree that flexbox is ready for use at all. If you work in or for any kind of even semi corporate company you’ll still have to support IE9 and mostly even 8. For IE10 and up there are nearly perfect fallbacks, but for IE8 and 9 there might not ever be. When dealing with things like payment flows you can not use flexbox yet.

    April 22nd, 2016 at 00:51

  6. Álvaro González

    In the early days there wasn’t any separation between content and style. Sites were a terrible mess of nested tables, cryptic non-semantic markup, inline fonts and colors, transparent GIFs…

    CSS was born to fix that. Now we have a terrible mess of nested divs, cryptic non-semantic markup, inline class names and attributes, CDN assets…

    It must be I’m getting grumpy as I get old.

    April 22nd, 2016 at 02:20

    1. Jason Knight

      What you said about the terrible mess of DIV reminds me of what a dearly departed friend — Dan Schulz — said about web development in the pre-HTML 5 days.

      “The people who sleazed out endless pointless nested tables for layout now just sleaze out endless pointless nested DIV”

      … and it’s true. That’s PRECISELY the change as far too many people vomiting up markup any old way have ZERO concept of semantics or the purpose of HTML, still using tags for their appearance and not their meaning, using classes with presentational names (See halfwit nonsense like OOCSS and by extension bootcrap), resulting in still using three times or more the HTML needed to do the job — to go hand in hand with the dozens if not hundreds of K of ineptly slapped together CSS doing 16k or less’ job.

      See how you now have many so called experts actually attacking the concept of separation of presentation from content… See all the fools duped into thinking that they are “designers” just because they know how to dick around with layers in Photoshop… See how outright idiotic halfwit dumbass ignorant BS like CSS pre-processors and frameworks have actually found people DUMB ENOUGH to use them by choice!

      All to make more work, more code, suck on more bandwidth, and in the process flip a giant middle finger at usability, accessibility, and sustainability — THEN these dipshits have the outright gall to call their ineptly slapped together rubbish that took more work and more time to create than more conventional methods “easier”?

      April 22nd, 2016 at 16:25

      1. Julien

        Whether you like it or not, CSS Preprocessors and CSS Framework helped tons of people out there. There are different context and solutions for every project. I often build a simple SPA for internal users and Bootstrap is very handy in those situations. For a larger project with decent budget and timeline, I would take the time to build my own stuff.

        April 27th, 2016 at 11:35

      2. Nige

        Jason, you sound like a bit of a troll in your second comment.

        Whether we like it or not the situation regarding the use of frameworks is always determined by it’s own circumstance. Horses for courses buddy.

        Not everyone that creates for the web has years of experience coding, has it taken you 20 odd years to realise this? It’s silly to expect this.

        The article itself will be helpful to those that aren’t necessarily aware of the drwabacks that come with using frameworks. But your second comment sounds like the pontificating of an arrogant dev.

        The web is a living thing and like all living things, it comes with flaws, not everyone that uses it and builds/designs for it, is an expert. That’s just life!

        April 29th, 2016 at 08:04

  7. Thierry Koblentz

    Hi Belén,

    You list 3 reasons for using a framework:

    – Speed
    – Best practice
    – Design

    I would add an important one: the lack of skills or knowledge to create your own solution free of bugs or issues.

    For example, you say people could use “flexbox” instead of a out-of-the-box solution (i.e. Bootstrap) to create their layout. But this means they will offer a broken experience to many users by switching to a layout that does not have great browser support. How is that a smart decision? Frameworks come at a cost (performance mostly) but at least they solve a problem that most people are not capable to solve by themselves.

    In my opinion, the goal should be to offer a satisfying experience to the end user, not to feel good for owning 100% of your code base.

    April 23rd, 2016 at 09:13

  8. Benjamin Gandhi-Shepard

    Great write up. I agree. If you can write CSS better than a framework, then do it. I like how Bootstrap has helped countless Devs make sites that look a lot less gross. But I hated that era a couple years ago when you had to know BootStrap to be called a knowledgeable frontend dev.

    April 24th, 2016 at 10:32

  9. David Murcof

    Yes you absolutely do need css Frameworks.

    The main reason is documentation.

    When I work with bootstrap my backend devs can easily understand the code when consulting the documentation. So I don’t have to invent shitty classes nobody understands and write bullshit documentations.

    Absolutely nobody cares for these aditionals css kilobytes.

    Another bi pro is fast prototyping. When I have to write my on stiles for every goddamn form over and over again ist is timeconsuming. I could write a standard css file for forms and buttons ans so on……… OH WAIT A MINUTE!

    April 25th, 2016 at 02:39

  10. Nico Burns

    Hmm… what kind of CSS frameworks is this article aiming it? I’m assuming it’s mostly aimed at the Bootstrap/Foundation kind of framework, in which case it has a point. However, I have that the approach taken by Inuit.css / ITCSS is much more helpful. They are focused more on code organisation, with a few helpful standard styles (which can be extended via SASS to avoid cluttering HTML code). IMO this is the best of both worlds: flexibility without having to write everything from scratch.

    April 25th, 2016 at 02:53

  11. Gary

    Very essential article for new comers in front end development. While interviewing, I have seen many peoples very good with bootstrap or foundation whereas failed to make 1 simple pre css responsive layouts. And many still avoid native css animations. People who are serious about web career must learn core css to make responsive and advanced animations. Instead of frameworks they must master in Sass/less.

    April 25th, 2016 at 03:00

  12. Dane

    I’m not a fan of the larger frameworks like Bootstrap and Foundation but I have found using Spacebase – helps me with a lot of best practices and helpers, mixins that can be used with SASS.

    April 26th, 2016 at 09:16

  13. Phil M

    A few of the comments above come off as arrogant and elitist.

    The web is used by all sorts of people for all sorts of reasons. So what if there are a few extra kb downloaded by a user if it means the difference between delivering a website on time vs late or never. Do people *really* have to wait until they are super skilled css ninjas before they can work in the industry?

    The article itself is fairly well balanced – it doesn’t overreach; it just points out that using a framework can come with a cost.

    Fair enough, you’re now informed and you can still go ahead and use that framework if the cost is justified by the benefits. Understand your target user and the devices they will use and makes your decisions based off that.

    Ignore elitist comments that try to belittle successful frameworks like bootstrap for any and all uses (I have no affiliation with them at all). Bootstrap, and other frameworks were developed for a reason and they fill a need. By all means, understand their purpose and try not to unnecessarily abuse them, but don’t be afraid of using them.

    April 26th, 2016 at 15:39

    1. Julien

      Absolutely agree with you. Best comment so far.

      April 27th, 2016 at 11:39

  14. Barbara Sykes

    Very nice & important article for newbies in front end development. Thanks for sharing :)

    April 26th, 2016 at 23:28

  15. JAson Witt

    When CSS frameworks were just becoming a thing I saw a post of forum that said “Build one yourself, then use someone else’s”.

    I took that to heart and spent about a month developing my own framework. It was pretty good for the time, too, but when I stated to actually use it I found that I ended up only using a tiny fraction of it. After spending all that time building the framework I realized that all my effort was in vain.

    Is 4000 lines of CSS really worth putting into you project if you only end up actually using 100 lines?

    April 27th, 2016 at 09:17

  16. Álvaro González

    To those who dismiss all this subject as elitist nerdy stuff (“who cares about a few extra KB, are you using a modem?”): how much time does a typical newspaper page with a 5 paragraph article need to fully load? In my 30Mbps cable connection the average must be around 15-20 seconds from my PC (ethernet), with peeks over a minute. If I browse with my 2014 tablet (wi-fi) it takes twice the time. And you’d better scroll carefully because it can be painful. Yes, it’s not all due to CSS (every time I open Developer Tools I see hundreds of HTTP connections loading a few MB worth of data) but the overall mentality is making the web more unusable than it should.

    April 28th, 2016 at 01:45

  17. SP

    Like all tools, I believe each has their place-css frameworks included-even if only in the smallest way. So whilst I disagree with extremist comments (in general too), I do agree that these should be used with consideration-meaning, you wouldn’t bring a sledge hammer to put down a corner of a sticker on a piece of paper. The real problem is how these frameworks are used. Sadly, I have just witnessed this little snippet to make this point “div.form-group.form-group-sm.form-inline.btn-group.btn-group-sm.has-warning”. LOL, perhaps hand-written css would make more sense here… :)

    April 28th, 2016 at 07:32

  18. Raj


    I totally hate using frameworks that are too bloated, as half of the time I don’t need their defined styles and would have to always override the styles causing more bloat in the CSS.

    I find that using just a grid framework like LOSS for example works great for web development, something which is lightweight.

    As for flexbox, we can definitely start using it today. I know IE 8 and 9 do not support it but we can always use Modernizr to fallback to floats. It’s all about making your code more future proof.

    April 29th, 2016 at 14:52

  19. Matthew TROW

    You make some valid points, however, I think it’s true to state:

    “Know how CSS works before using a framework”

    The biggest issues we are seeing with frameworks and css post processing, is that of a lack of knowledge of fundamental CSS best practices.

    Interestingly, with the label-warning example you described, that actually gets around some of the issues of “Over-specific CSS selectors”, because it’s modular.
    It also saves bytes, as the core label class has the common properties and the class is extended with just the differences.
    If you were to use just label-warning, what if you had another label type almost exactly the same, but it had blue text? – you could either replicate the entire class, including attributes that were identical OR you get modular, exactly in the manner of ‘label label-warning’

    I really don’t think the questions Why you should or why you shouldn’t are useful.
    Because properly crafted frameworks are exceptionally modular, you can pick just the bits you want.
    The alternatives are:

    1. Continually recreating the same patterns
    2. Writing your own framework

    Both these points have flaws.
    Take the most popular framework and work out the not only the amount of man-hours, but also the amount of contributors to that framework. You’d be hard pressed to come up with a framework of the same quality.

    Far better to use parts of the framework you want, extend it with your own and others code and give back to the community.
    For this, you need to know CSS – but using frameworks will actually teach you how to write effective modular CSS.
    It’s a win win, once you’ve mastered a framework, you can take use all of it, some of it, extend it, mix it with another framework AND keep your code lean.

    May 4th, 2016 at 02:00

Comments are closed for this article.