---
title: "Quitting Tailwind by copying it"
locale: "en"
url: "https://irz.fr/en/articles/tailwind-exit-css-layers-en"
markdown_url: "https://irz.fr/en/articles/tailwind-exit-css-layers-en.md"
category: "tech"
tags: ["Tailwind", "CSS", "frontend", "architecture"]
published_at: "2026-08-24T17:30:00.000Z"
author: "Mathis Renaud"
translation: "https://irz.fr/fr/articles/tailwind-exit-css-layers-fr.md"
---

# Quitting Tailwind by copying it

Eight years after celebrating a way to write CSS without writing CSS, Julia Evans moved her sites back to hand-structured stylesheets, copying Tailwind's own systems along the way.

Eight years ago, Julia Evans published an enthusiastic little post about discovering Tailwind, a tool she summed up as a way to style your site without writing any CSS.[2](https://jvns.ca/blog/2018/11/01/tailwind--write-css-without-the-css/) In mid-May she did the opposite: over roughly a week, she migrated a couple of her sites to semantic HTML and hand-written CSS.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/) The interesting part of the story is not the exit itself. It is what she carried out of the building. The reset stylesheet from Tailwind made the trip, along with its font scale and even its screen-reader utility class, all recopied into plain CSS files she now maintains herself.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

## Why leave

Her reasons are refreshingly unglamorous. Since 2018, Tailwind has grown far more dependent on build tooling, to the point where she suspects (her own question mark) that newer versions cannot be used without one. She never adopted that workflow, so for years she simply stayed on Tailwind v2 and shipped the whole stylesheet anyway: files of 2.8 MB named `tailwind.min.css`, 270 KB once gzipped, sat in many of her projects. "It feels a little silly," she writes.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

> The single-file habit
> **Everything shipped, whatever the page uses**
> - tailwind.min.css loaded in many of her projects: 2.8 MB
> - the same file once gzipped: 270 KB
> - lines of preflight she actually kept after the migration: ~200
> She never used the recommended build setup, so the whole framework traveled with every page.

Beyond the payload, her list gets longer. She is simply better at CSS now than in 2018, while the framework's limits keep getting in the way of what she calls Weird Stuff. Maintaining projects that mix Tailwind with vanilla CSS stopped being fun, and curiosity about more semantic HTML provided the last push.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

There is a second act to this story: she documented the starting point herself. Her 2018 post celebrates the first version of her zine store, put together in two evenings, with Tailwind arriving as a single CDN link and no build step at all. At the time she was googling "how do I center div" for what she says was the 500th time, and her fallback markup included divs carrying ids like WRAPPER-WRAPPER-THING.[2](https://jvns.ca/blog/2018/11/01/tailwind--write-css-without-the-css/)

> Eight years apart
> **Same author, opposite bets**
> - One CDN link, zero build, utility classes stacked in the markup.: 2018
> - Named layers in plain CSS, native nesting, esbuild only to bundle for production.: 2026
> Sources: jvns.ca, November 2018 and May 2026.

## The reset, copied

When the time came to structure her own CSS, Evans realized the intimidation was misplaced. Every codebase juggles layouts, fonts, colors and common components; what keeps them from collapsing into chaos is having a system for each. And Tailwind had already given her systems for some of these.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

So the migration starts with theft, in broad daylight. She opens the Tailwind stylesheet and copies the first 200 lines, the preflight reset, straight into her own project. Parts of it live in her reflexes without her ever noticing, she suspects: every element set to `box-sizing: border-box`, the default line-height of 1.5.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

That detail deserves a pause. A developer who leaves a framework usually frames it as liberation from arbitrary decisions. In our reading, the situation is closer to the reverse: the framework had been making hundreds of small decisions she agreed with, and the honest move is to adopt them explicitly rather than rediscover them by accident.

## One file per component

The bulk of the new CSS follows three rules borrowed, in spirit, from component frameworks: each component gets one unique class, its styles never override those of another component, and each lives in its own file. Editing one thing means thinking in terms of roughly a hundred lines, and she estimates that about 80 percent of the CSS she actually wants to change sits right there in these component files.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

Nothing actually enforces the arrangement: no web components, no `@scope`, just a convention she tries to respect. That seems to be enough for her, since on its own the convention already feels like a big improvement over hoping nothing collides.

Around the components sit the supporting layers, kept deliberately small: every color must be listed in one `colours.css`, while font sizes come from variables lifted straight out of the Tailwind scale, such as `--size-xs: 0.75rem`, an approach she finds more verbose than `text-lg` yet acceptable for now.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

The "base" layer of site-wide styles is the smallest of all, containing exactly two rules she feels confident imposing: a centered 950-pixel column for sections plus orange links. Her plan is to grow it bottom-up, promoting styles into the base only once they prove genuinely common.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

> Nine layers, four load-bearing
> **Structure without a framework**
> - Preflight copied almost verbatim.: Reset
> - One class, one file, no overrides.: Components
> - Every color and font size declared once.: Tokens
> - Two rules, grown bottom-up.: Base
> Utilities, spacing, responsive grids and the optional build step complete the map she describes.

## Grid instead of breakpoints

The clearest break with the Tailwind years concerns responsive design. Before, she leaned on media query utilities like `md:text-xl` and decided element by element how things should behave at each size. Now she builds flexible grids that adapt with few or no breakpoints. One pattern, `repeat(auto-fit, minmax(min(100%, 400px), max-content))`, settles on one column or two depending on the space available. Another favorite is `grid-template-areas`, a feature she finds amazing and suspects Tailwind cannot offer.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

Spacing remains unfinished business, by her own admission. Her current principle pushes responsibility outward, toward the outer layout components, with tricks like the owl selector (`section > *+* { margin-top: 1rem }`) to space children evenly. Compared with scattering padding around at random until the page looked right, as she describes her old habits, it is more principled but still far from a full system.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

Build tooling gets the same pragmatic treatment: development needs nothing anymore, since CSS supports imports and nesting natively. For production she can bundle with esbuild, a tool she accepts despite generally avoiding build systems, on the grounds that it sticks to web standards and ships as a static Go binary.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

## The reason underneath

All of this could read as a performance tweak, yet Evans is explicit that the deepest reason sits elsewhere. Three years ago she read an essay by Elaina Natario on Tailwind and the femininity of CSS, which argues, borrowing Jeremy Keith's words, that programmers hear CSS is simple, assume it is easy and blame the language when it resists them. The piece never let go of her.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)[3](https://thoughtbot.com/blog/tailwind-and-the-femininity-of-css)

Her response over the last decade was to take CSS seriously as a technology instead of devaluing it. Learning it properly dissolved old frustrations, she writes: centering had been solved long ago, in several ways, since centering genuinely names several problems. "CSS is hard because it's solving a hard problem!"[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

And then comes the line that gives the migration its weight. In her view, Tailwind contributes to the devaluing of CSS expertise, and she wants no part of that, "especially in this time of LLMs where it feels more important than ever to value humans' expertise."[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

{% irzSlide layout="quote-evidence" variant="dark" title="A decade-long position, not a vibe shift" body="Evans decided years ago to answer “CSS is hard” by getting better at CSS. This migration applies that choice to her own stack." value1="2018" label1="Writes up styling a site “without writing any CSS.”" value2="2021" label2="Natario warns that utility frameworks hinder deep learning of CSS." value3="2026" label3="Evans exits, citing respect for the language and for human expertise." footer="Quotes condensed from the cited posts." /%>

## Seven hundred comments

If the reception means anything, she touched something shared: the main Hacker News thread collected 698 points along with 397 comments, and Simon Willison quoted her passage on respect for CSS the day after publication.[4](https://news.ycombinator.com/item?id=48158400)[5](https://simonwillison.net/2026/May/16/julia-evans/)

Neither the thread nor her post settles anything about Tailwind at scale, and she does not pretend otherwise. Her conclusion concerns her own projects, the ones where she now wants constraints she chose. The features on her curiosity list for next time, cascade layers, `@scope`, container queries and subgrid, read like a to-do list the platform has been quietly preparing for exactly this kind of return.[1](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)

The framework never really left her CSS. It moved out of the dependency list and into conventions she can open and read whenever she likes.

## References

1. [Julia Evans, Moving away from Tailwind, and learning to structure my CSS, May 15, 2026](https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/)
2. [Julia Evans, Tailwind: style your site without writing any CSS!, November 1, 2018](https://jvns.ca/blog/2018/11/01/tailwind--write-css-without-the-css/)
3. [Elaina Natario, Tailwind and the Femininity of CSS, thoughtbot, December 15, 2021](https://thoughtbot.com/blog/tailwind-and-the-femininity-of-css)
4. [Hacker News discussion, Moving away from Tailwind (698 points, 397 comments)](https://news.ycombinator.com/item?id=48158400)
5. [Simon Willison, A quote from Julia Evans, May 16, 2026](https://simonwillison.net/2026/May/16/julia-evans/)