Every front-end developer uses CSS frameworks, even those saying they don’t.
Anytime the “what’s your favorite CSS framework” question pops up, you read the same comments: a bunch of developers expressing their love for framework X or Y, and others stating they don’t use frameworks.
Some of the reasons why some developers say they don’t use CSS frameworks:
- Frameworks are opinionated.
- Why would I need a framework when I can write clean CSS myself?
- Frameworks are bloated with stuff I don’t need.
But what is a framework, exactly?
"A framework is a supporting structure around which something can be built."
A framework doesn’t need to be opinionated. Its CSS can be as clean as yours (or it could literally be yours). It can be super slim, to the point where it includes only a bunch of reusable rules.
If you do one of the following, you’re using a framework even if you say you don’t:
- You have a bunch of utility classes that you copy and paste from project to project.
- You have a set of basic rules (e.g., for typography and spacing) that you copy into new projects, and then tweak to accommodate different needs.
- You have a boilerplate for the style of buttons and forms that is easy to customize.
- In general, in any case where you reuse something across different projects.
There’s only one case when you can say you don’t use a CSS framework, and it’s the truth: if you start a project with your CSS files completely blank.
But seriously, why would you do that? 🤔
I know I’m being pedantic. “When I say I don’t use a CSS framework, I’m referring to Bootstrap, not 20 lines of code!”, I hear you scream. However, I think there’s a misleading message that is delivered to young developers: “Frameworks are bad. If you were a good developer, you’d write clean CSS from scratch”. And yet millions of developers download Bootstrap every month. Are they all making a mistake? Not at all.
You could use a super slim framework or create one yourself, and it would be fine. You could use a heavier framework or create one yourself, and it would be fine.
Starting from (literally) scratch every time does not prove you’re a good developer.
Let me walk you through the main problems a framework helps you solve and why we all need one.
Global styles and abstraction
When Claudia and I started working on the CodyHouse Components project (a library of HTML, CSS, JS web components), we soon realized how important it is to have global styles and abstract rules.
A global style is a rule that, when modified, affects all the components it crosses (e.g., a buttons.scss file where you store the style of your buttons).
A CSS abstraction is a rule that gives the same result regardless of the element it is applied to (e.g., utility classes).
Global styles make your project customizable. For example, if you create a reusable typography.scss file where you define the type scale, you can 1) edit the type scale and affect all the components of your current project or 2) set a custom type scale for your next project.
CSS abstractions make it easier to create component variations without the headaches caused by naming things. For example, imagine you create a new component. If you want to create two class modifiers where the text is aligned in the center or right, you end up doing the following:
Then you create another component and have the same ‘issue’. Once again, you create two new class modifiers:
An alternative approach would be creating 3 utility classes (abstractions):
Now you can have infinite components and apply the same utility classes to align text.
I’m not suggesting you should create utility classes for everything (even though some frameworks do so, and developers love them). Find your own balance, create the abstractions you need.
Do not reinvent the wheel
If you come up with a pattern that works, why wouldn’t you extend it to new projects (and include it in your framework)? For example, you start working on accessibility and soon realize how handy it is the .sr-only utility class:
Is there any reason why you shouldn’t use it in all your projects? Nope.
Getting back to your old projects doesn’t need to be THAT painful
Opening up an old CSS project is a pain; we all know that. However, it doesn’t need to be THAT painful. Using the same framework across multiple projects means working with patterns you’re already familiar with. If you use the same mixins, global settings, grid rules, and utility classes, you’ll need less time figuring out how to do stuff.
For example, let’s imagine you have created a scale of spacing values:
You know you can go ahead and modify a component using one of the scale values:
The spacing values may vary in different projects, but the way you apply them is the same. You go ahead and set padding: var(--space-md);. If it’s too small/big, you can pick another value (or edit the scale).
The alternative approach would be:
- First, figure out how spacing rules were set when the project was initiated.
- Then, apply the spacing rules.
That extra step makes all the difference in the world. It’s where the frustration lies: figuring out things when you, or someone else you work with, already went through that process before.
Frameworks evolve and get updated (e.g., when you learn new patterns and replace old ones). There will be cases when you still need to remember how/why some rules were set in the first place. It sucks, but working with reusable patterns (framework) means reducing the number of times this happens.
Learn by building reusable patterns
One more advantage of creating your own framework is learning to identify reusable patterns. You find that piece of your CSS puzzle that could work across multiple projects, and decide to store it in a safe place (your framework).
Or, you can learn from frameworks created by other developers. Question why that rule was abstracted. If you can’t come up with an answer, google it; or ask the author.
The process of questioning what you do and discovering the mechanics behind a decision is what makes you learn. Not the assumption that you have to come up with all the solutions yourself.
Conclusion
A CSS framework is a tool. It’s not good or bad, and it doesn’t define you as a developer. When you find a pattern that works, save it. If you find a framework that ticks all your boxes, use it. As long as you learn in the process, nothing bad comes from using it. Quite the opposite.
If you’re looking for a lightweight front-end framework for building accessible, bespoke interfaces, check out CodyHouse!
Top comments (1)
Hey Sebastiano! It's Rob from the old SVG Immersion from back in the day. I interviewed you guys (maybe 8 years ago?). Anyway, great to find you here :-)
I agree about frameworks overall. I keep telling folks to stop saying these things like "it's better to use a framework" "never use a framework" "always write it all in your own CSS". Such broad sweeping generalities. My advise to folks is to use all the frameworks. Then tear them down. Then write you're own framework and compare it. Then write custom CSS. Then right a bunch of toys. Then do it all at the same time. Do an a11y audit on 10 framework tabs implementation and see which ones got it totally wrong. Which one did it so well that you even learned about an aria or approach you had all wrong. Then go compare to what the web-aria guides and MDN say and what not. This is how I learn.
Folks are so tribal and polarized. We all have to think. We all have to read some source code. Some documentation. Some best practices. Then we have to question it all. It's the only way. I think I'm saying mainly the same thing Sebastiano but in my own way. The reality is I'm a big admirer of your guys work so I know you both are doing this and more!
Cheers 😄 💪 ⭐ 🍰