Why I ditched heavy CSS frameworks for plain CSS
By Jossy Oseahumen Francis
For years, I reached for a heavy utility framework on every new project without thinking twice. It was fast, it was familiar, and it meant I never had to name another CSS class again. But over the last year I've quietly moved almost everything back to plain, hand-written CSS — and I don't regret it.
The problem wasn't the framework
To be clear, utility-first CSS frameworks are genuinely good tools. The problem was how I was using one: as a crutch to avoid understanding the cascade, specificity, and the box model properly. Every project ended up with the same soup of utility classes stacked six deep on a single element, and editing someone else's markup six months later meant deciphering a wall of abbreviations instead of reading intent.
"If your HTML needs a legend to be readable, the styling system has failed the next person who opens the file."
What changed my mind
Readability over brevity
A class like .hero-title tells you what something is. A class like flex items-center gap-4 text-2xl font-bold text-zinc-900 tells you what it looks like today, in this breakpoint, in this state — and nothing about its role in the page. Naming things is hard, but it pays off every time you or a client revisits the project.
No build step, no tooling drift
Plain CSS files never go out of date. There's no framework version to upgrade, no config file to relearn, no CDN dependency that might change behavior overnight. You open the file, you edit the rule, you save. That simplicity matters enormously for handoff projects and long-lived client sites.
The design system is the stylesheet
Spacing, colors, typography — all centralized in a handful of CSS custom properties at the top of the file. Change one variable and the whole site updates. That's not unique to plain CSS, but it's refreshingly direct without an extra abstraction layer in between.
The real-world impact
I rebuilt a client's marketing site using hand-written HTML, CSS and JavaScript, replacing a bloated page-builder stack. The results after one month were hard to argue with:
- Lighthouse performance score: 52 → 97
- CSS bundle: 210kb → 12kb
- Time to first contentful paint: 3.4s → 0.8s
- Bounce rate: −19%
What I still miss from frameworks
It's not all upside. A few things I still have to build by hand instead of getting for free:
- Pre-built complex components like modals, dropdowns, and date pickers
- A ready-made responsive grid system for very complex layouts
- The instant visual consistency a shared utility scale gives a team of multiple developers
For solo projects and small teams, none of that outweighs the clarity of a stylesheet you can read top to bottom and actually understand.
My recommendation
If you're working alone or in a small team on a custom site — a portfolio, a landing page, a small product — plain HTML, CSS and JavaScript is a completely reasonable, often better choice. The learning curve is just the fundamentals you already half-know. After that, you'll ship something you can maintain for years without fighting a dependency.
If you're coordinating a large team across many projects and need enforced consistency at scale, a utility framework still earns its keep. Use the right tool for the job.
If this was helpful, share it with a friend who's still fighting specificity wars. 🌱