Knowing how to code is only part of what makes a good developer. The ability to decide when is the time to avoid custom coding and rely on the appropriate third-party tool is almost equally important.

When it comes to frontend development, in particular, using a CSS framework, be it Bootstrap, Tailwind, Bulma, or whatever, has become standard practice. The benefits of such tools are apparent: you can build solid layouts fast, without having to worry about the little details or improvise on responsiveness.

Nothing comes without a cost, though, and CSS frameworks are no exception, having their own drawbacks.

1. Spaghetti HTML

Separation of concerns is usually a good thing and keeping the HTML for the structure and the CSS for the appearance has always been considered a good practice. Using a framework, though, forces you to overuse classes and modify your markup in a non-optimal way, nesting divs within divs, trying to adapt to the frameworks’ conventions, in an attempt to avoid touching your .css files. A few years back I could justify that practice, as the framework could take care of things like browser compatibility, prefixes, and weird layouts.

Nowadays, though, with improved browser compatibility and technologies like Flexbox and Grid, doing <div class=”flex”> instead of using display: flex; not only offers zero benefits but also limits your options. Which brings us to the next drawback…

2. Limited potential

I can find meaning in using a CSS framework when you must develop a website and you don’t have a design that should be followed to the pixel or if you are building a prototype. Then, a framework with its ready-made components could help you build something presentable and consistent, avoiding improvisations. If you need to transfer a custom design to HTML, though, and depending on that design’s complexity, it is not rare that a framework could even turn out to be an obstacle rather than a help.

In cases like that, you start by trying to adapt your markup to the framework’s logic, nesting elements in often unnecessary ways, overcomplicating a markup that could (should) be much simpler until you realize that handling everything with classes is simply not enough. Eventually, you end up writing a lot of custom CSS anyway, overriding the frameworks’, which leads to not only spaghetti HTML but spaghetti CSS as well.

3. Unused code

Unused code on CSS frameworks is like the dark matter of the universe. It accounts for the big majority of your total CSS, but it remains invisible on the frontend. Contrary to the dark matter, though, whose nature is still unknown to us but we can tell that it plays a role in the grand scheme of things, the “dark code” of a framework is completely useless for your site, only bloating it with many extra kilobytes.

4. Future uncertainty

How certain can you be that in one year from now you will still be using the same framework? If you do, great. If you don’t, though, and you have to work on an old project of yours, trying to remember the old conventions while you have already moved to the next big thing of CSS frameworks, with its own conventions, can be disappointingly hard.

Even more disappointing is when you have to work on somebody else’s CSS, and that somebody happens to use a different framework than yours. In that case, adding your own framework to the mix is an obvious no-no, so you will have to either learn that other framework or just go and write your own vanilla CSS on top of that.

Which brings us to the final drawback…

5. The danger of un-learning CSS

Frameworks come and go. Yesterday it was Bootstrap, today is Tailwind, tomorrow it will be something else. Searching for the best framework and then learning its rules can be time-consuming, but that is the least of it.

The major drawback here is that you might shift your focus to the wrong thing. Instead of learning CSS, you learn the logic of a framework, often forgetting what is under the hood and how to write actual CSS. The funny thing is that what is happening under the hood is not so much complicated anyway, and it would make much more sense for your evolution as a developer if you invested in it in the first place.

After all, the knowledge you acquire from learning a framework has an expiration date and is limited to the framework’s environment. If at some point, you decide to switch, all the hours that you spent learning the old framework seems like wasted time, as the knowledge that you obtained is of no use anymore. Learning the underlying technology, on the other hand, will never become obsolete (at least as long as the technology itself remains relevant) and will be valuable no matter the tools that you end up using.

The alternative: Writing CSS from scratch

Reading all of the above might give you the impression that I do not like CSS frameworks. Well, you would be right. After using some of them on a few projects I quickly realized that it is not my cup of tea and decided to avoid them in favor of writing my own CSS. Of course, that comes at a cost too.

Building almost all of your CSS from scratch (with the exception of the normalize CSS) requires some thinking beforehand, in order to organize your work in a way that makes sense, is efficient and future-proof. If you decide to go that road, you might want to take a look at a few generic tips:

1. Go mobile-first

It might seem intimidating at first, but the mobile-first principle can be a blessing in disguise. Getting used to it can help you write much cleaner, better-maintained CSS and save you time in the long run.

2. Pick a CSS methodology

Instead of improvising in creating your own rules, you can adopt one of the existing, “battle-tested” methodologies, be it BEM (especially the naming conventions), OOCSS, Atomic CSS, or whatever you find that suits you best.

3. Be consistent

Give yourself some time to study best practices and try to keep it consistent. Consistency can have many forms, such as using the same naming conventions for classes, preferring tabs instead of spaces or vice-versa, choosing how to describe colors, etc. Using a common methodology on all your projects will help you be faster and more efficient, being able to easily resume a project even after months.

4. Use a preprocessor

Learning to use a preprocessor like Sass or Less and/or a post-processor like PostCSS can benefit you in multiple ways. You will be able to organize your styles better, even reusing things between projects, take advantage of variables and functions (mixins), or even add autoprefixers.

5. Don’t be afraid of Flexbox and Grid

Ditching the flex framework that I’ve been using in favor of learning the actual Flexbox was one of the wisest choices I’ve made. I realized that it was much easier than I thought and gave me a great deal of freedom, compared to the framework. Grid can be more intimidating at first, but as long as you figure out its logic you add an all-powerful weapon on your CSS armory.  css-tricks.com has great guides for both Flexbox and Grid and it is the perfect place to get started.

So, what do you think? Is writing CSS from scratch worth it or are you rather stick to your framework? At the end of the day, of course, all that matters is what makes you more productive and that can’t be the same for everyone. Being aware of the limitations and the trade-offs of each solution, though, would definitely not hurt.