I saw a short think piece by @urielbitton recently on why people should "stop using CSS frameworks." It was meant to start developer discussion more than anything, since there are definitely merits to rolling your own design system from scratch. Still, with a title like that, it sparked... quite the uproar in the comments 😆
I posted my own response on some of the nuances to explore before writing off frameworks for good. A kind commenter suggested it be its own post (thanks for the support y'all!), so without further ado...
Here's my clap back 👏
Understanding the spectrum of CSS frameworks
First, I'd want to draw a distinction between
Pre-styled, prescriptive, all-in-one frameworks like Material UI and Bootstrap
Hands-off, unopinionated, utility frameworks like Reach UI and Tailwind CSS
I'd consider both camps to be "CSS frameworks," but for different audiences and different use cases.
1. The case for all-in-one frameworks
⭐️ This category is all about developer guidance, giving you the building blocks you need for powerful web apps (even if you don't have the domain knowledge). Above all, these are important for developers that need to focus on the business logic and product vision, but don't need hyper-bespoke CSS to get there.
Accessible by default
The training wheels enforced by these frameworks ensure accessibility guidelines are met without as much research on the developer's part. You may not think about it, but hacking together dropdowns and tab sliders that look good won't always work well for all people. I recently wrote a longform post on building an accessible navbar for this very reason; there's so many little things to consider that Material UI et al. will consider ahead-of-time!
Given how mature popular CSS frameworks have become, they have a component for basically every accessibility concern you can think of. This is a huge win for teams without the resources to audit and fix a11y issues.
Inoffensive visual identity
These sorts of frameworks also enforce a visual identity out of the box. Yes, this does cause websites built on Material UI, Bootstrap, etc. to feel a bit cookie-cutter. Still, these are sensible defaults to build from, especially for a) developer teams lacking a design department and b) internal tools that don't need the customization effort.
Plus, there are gray areas in frameworks like Bootstrap that do allow you to build a visual identity on top of their tools. Heck, I just worked on a project in this camp! We just used Bootstrap for the 12 column grid (which my team was most comfortable with using), and themed the default styles into oblivion.
That said, I do agree with a point raised by Uriel on this front:
"Having custom styles is complicated (overriding issues) and will require multiple CSS files to be loaded."
For full-on component libraries like Material UI, it is pretty difficult to customize beyond colors and fonts. You can quickly fall into the weeds of excessive prop passing, mismatched styling across your site, and the infamous !important bonanza 😞
This is why I'd suggest solutions like Material UI only if your "visual identity" won't diverge from the defaults too much. If you find yourself outgrowing the walled garden though, there's always camp #2...
2. The case for utility frameworks
⭐️ This category is all about developer expediency, providing helpful abstractions for common use cases without prescribing a look and feel to work from. These systems offer a lot more freedom by being, well, a lot smaller out of the box!
"Utility" is a very generic label that could apply to anything in UI-land. For simplicity, I'll just explore 2 major movements I've seen emerging: class-driven frameworks, and functionality-first frameworks.
CSS class utilities - Tailwind and Bulma
Frameworks like Tailwind are really shaking things up. It's the first framework I've seen to go all-in on class-based styling. In other words, why can't every CSS property be its own class in your HTML?
At first, this sounds like a recipe for disaster. But it offers some pretty interesting benefits:
-
Media queries are standardized right out the gate. Instead of loosely defining breakpoints like
max-width: 860px, you can simply append "small / medium / large" to the front of your HTML classes. For example, here's how you could dynamically change an element's size between mobile and tablet:class="h-16 w-16 md:w-24 md:h-24" - Shorthands can speed up experienced teams, without abstracting the CSS away too much. Since every class is a 1-1 with a CSS property (or small set of properties), you are still translating to core CSS concepts every time. This dispells the fear of using all-in-one frameworks like Material UI, where the CSS is completely hidden from developers most of the time.
This framework has a laundry list of pros and cons that deserves its own article. Luckily, @swyx wrote an amazing evaluation for his own needs that's worth reading 😁
I also want to mention Bulma in this section, in case the breadth of Tailwind is too intimidating for you. I'd consider it a "Tailwind-lite" with a lot of the same philosophies.
Bare-bones UI libraries - Reach UI
Reach UI is my favorite example in the "functionality-first" camp. In short, Reach UI gives you a set of React components with prebuilt aria labels, state management, and some lightweight CSS styles sprinkled on top (mostly for changing display properties). The goal here isn't to enforce a visual identity; it's to provide the least amount of code possible to create usable, accessible UI elements ✨
In the end, you're free to add your own layer of styling and JS logic on top. The documentation actually guides you through overriding the defaults! I'm a CSS warrior myself, so I lean on this type of CSS framework to get things done (as long as I'm using React of course).
I'd consider this sort of framework to be a master-class on inversion of control, and I hope more frameworks pick up on this pattern.
Wrapping up
Overall, I think writing off CSS frameworks is a bit of a hand-wavy statement to make given the huge landscape of tools out there right now. There will always be a place for prebuilt solutions like Material UI; if anything, I see them as one step removed from powerhouses like SquareSpace or Wordpress (closer to the code, but with a lot of details abstracted away). And for teams that don't want to be tied down, solutions like Tailwind and Reach UI should fit the bill for adding handrails without losing visual identity.
Still, keep hacking away Uriel! We all have opinions, so just use what works best for you and your team 😁
Learn a little something?
Awesome. In case you missed it, I launched an my "web wizardry" newsletter to explore more knowledge nuggets like this!
This thing tackles the "first principles" of web development. In other words, what are all the janky browser APIs, bent CSS rules, and semi-accessible HTML that make all our web projects tick? If you're looking to go beyond the framework, this one's for you dear web sorcerer 🔮
Subscribe away right here. I promise to always teach and never spam ❤️
Top comments (6)
In my experience, these frameworks usually fail when it comes to accessibility or semantics. Disabled outlines, weird contrast ratio in hover focus states, etc. etc.
SemanticUI (a framework with almost 50k stars) has so terrible focus effects that navigating trough their buttons is like peekaboo game. I can only imagine how people with disabilities are struggling with it.
These frameworks are good if you have to get stuff done real quick but they are not as great as people think.
Creating accessible UI is not easy either. It looks like you have tried to make this navbar accessible but something went wrong because navigating in this app using keyboard is at least hard. I cannot get focus on menu icon, and when I open it with my pointer then focus is somewhere behind.
This doesn't mean you are bad developer. It proves my point which is - making accessible UI is really hard and using a ready solution does not guarantee that your app is going to be accessible or semantic (not saying you actually used one).
UI Frameworks are just
greatfine but I can't imagine using them on gov or edu sites.I'm glad you went ahead and wrote the article. As said previously, very insightful, very good read.
This is point is one of the strongest for having a CSS framework. Design principles are hard when you are a beginner developer, and for many developers who just don't really understand design.
The "cookie-cut" type of design system is better than none at all.
Great points Ben! I think we should do both — use frameworks, tear them apart, analyze them. Take the good, ditch the bad. Write your own. But also write custom CSS. Large projects. Toy projects. You need them both. It's like an athlete balancing doing drills versus match play. You need it all 😄 — lastly, we need to think for ourselves and go look at the source code. And write. Really it's like language. Read. Write. Read some more. Write some more. I think it's the only way 😄 ⭐ 💪
Oh and I agree that sometimes the frameworks (or really libraries) fail at a11y. But sometimes they're really good. Or, you can see them improving rapidly. I have seen ChakraUI make some notable improvements from 2020 to 2021 for example. Someone there made a concerted effort no doubt.
Very interesting, good post! You bring up very good points.
I appreciate that you understood the point of my post as well :)
I don't think "stop using CSS frameworks.". It reduces your time. However, the stereotype is not quite as good. You can grow more from it.
Cool.