Our Rails testing friend, Jason Swett, has an unpopular opinion: don’t use third-party CSS frameworks. I don’t think he goes far enough. In fact, I believe you shouldn’t use any frameworks—not even first-party ones.

Why Use a Framework?

Before diving into the problems with frameworks, let’s quickly review why we use them in the first place. A few major problems CSS frameworks aim to solve include:

• Pre-built UI Components: A solid framework provides a wide range of ready-made components. This allows you to quickly drop in elements and focus on solving your actual business problems.
• Accessibility: I’m not an accessibility expert, and every time I revisit the topic, I discover new ways to make systems more inclusive for everyone.
• Quality Design: CSS frameworks are often developed by dedicated teams focused solely on creating polished, high-quality design systems. For smaller teams, it’s unlikely you’ll produce a more robust general-purpose UI toolkit on your own.

The Problems with Third-Party Frameworks

Third-party frameworks offer substantial value—but they also come with serious drawbacks:

• Customization: Most frameworks provide limited customization. More flexible ones include configuration tools, but these only cover what the original authors anticipated you’d want to change. Modifying the source directly leads to painful upgrade and maintenance headaches.
• Upgrades: Upgrading frameworks, especially smaller or less-established ones, can be challenging. Even minor changes can break your system. Moreover, upgrades happen on the maintainer’s schedule, not yours, potentially leaving you stuck waiting for a critical fix.
• Commitment: Framework CSS classes become deeply embedded throughout your entire codebase. If you ever decide to switch frameworks, you might have to scrap much of your front end. Frameworks demand long-term commitment—they expect marriage, but only treat you like a friend.

These issues explain why many projects end up mixing multiple frameworks.

What’s Wrong with First-Party Frameworks?

First-party frameworks solve some of these issues, particularly around upgrades and maintenance, but they introduce their own problems. Smaller teams often lack the time or resources to create polished, scalable frameworks.

CSS also presents a unique problem: unlike programming languages, you can’t easily wrap or isolate a CSS framework from your codebase. Its classes directly touch your frontend, making true separation impossible.

That’s why I recommend avoiding frameworks entirely.

Here’s my proposal: enjoy the flexibility to use and customize code like a framework would allow—but without the coupling or dependency baggage.