Imagine building a magnificent, sprawling city. For years, you’ve relied on pre-fabricated kits – walls, roofs, windows, all perfectly sized and ready to snap together. It’s fast, it’s efficient, and for a long time, it feels like the only sensible way to construct anything. But then, you start to notice something. Every building, while functional, carries a familiar stamp. The unique character, the little architectural quirks that make a city truly memorable, are harder to achieve. This, in many ways, mirrors the journey some developers are taking in 2026, moving away from utility-first CSS frameworks like Tailwind and back to the foundational craft of structuring their own CSS.
As a reviewer for agntbox.com, I’m always looking at what works and what doesn’t in the AI toolkit space. But sometimes, the most interesting trends aren’t about the newest AI model, they’re about how we build the front end that presents those AI tools. And right now, the talk about CSS structure is a major one.
The Tailwind Era
Eight years ago, I was excited to discover Tailwind. Like many, I had no idea how to structure my CSS back then. Tailwind offered an appealing solution, especially for developers who, like Jerome Gill noted on LinkedIn, have come to see it as the de facto way to handle frontend styling in 2026. For several years, it’s been excellent, streamlining development with its utility-first approach.
The speed and consistency Tailwind provided were undeniable. It was like having a massive toolbox where every single tool had a singular, clearly defined purpose. Need to add some padding? There’s a class for that. Want to change text color? Another class. This approach certainly accelerated development, particularly for projects where speed was paramount.
A Shift Towards Control
However, the conversation is changing. On May 15, 2026, the discussion “Moving away from Tailwind, and learning to structure my CSS” surfaced on platforms like Hacker News, garnering attention even with a modest 34 views initially. This isn’t about abandoning efficiency; it’s about re-evaluating where true efficiency and long-term design flexibility lie.
Developers are now transitioning from Tailwind CSS to more traditional CSS methods. Why? For better control and structure. This shift isn’t just a nostalgic glance backward; it reflects a desire for more personalized and nuanced web design approaches. It’s about being able to paint with a full palette, rather than being limited to a pre-selected set of colors.
The Case for Semantic HTML and Custom CSS
Julia Evans shared her experience migrating personal sites from Tailwind CSS to vanilla CSS with semantic HTML. Her outlined CSS methods highlight the core of this movement. The emphasis is now firmly on semantic HTML and custom CSS for improved design flexibility. This means writing HTML that describes the content’s meaning, not just its appearance, and then styling that content with custom CSS rules.
This approach allows for a level of design customization that can be challenging to achieve when primarily relying on a utility framework. When every element’s style is dictated by a multitude of utility classes, making global or even component-specific design changes can become a process of sifting through many classes. With custom CSS, changes can be made in one place, affecting multiple elements more predictably.
Beyond Utility-First
There’s a growing sentiment that reducing CSS to merely a subset of utility classes, as some perceive Tailwind, can obscure the underlying principles of good CSS architecture. The “yelling at clouds” observation that people are being led to believe Tailwind is just a subset of CSS, only to realize years later that proper CSS structure is a distinct skill, rings true for many.
This trend underscores a renewed appreciation for understanding the cascade, specificity, and organization inherent in well-written CSS. It’s about building a foundation of styling that is not only functional but also maintainable, scalable, and adaptable to evolving design needs. For those of us who review toolkits and methodologies, this move isn’t a rejection of progress, but rather a refinement of our approach to building for the web. It’s about choosing the right tools for the job, and sometimes, the right tool is the one you craft yourself.
đź•’ Published: