Julia Evans migrated small sites from Tailwind v2 to vanilla CSS, borrowing Tailwind’s reset, color palette, and font scale as CSS custom properties.
Key Takeaways
Copied Tailwind’s preflight reset and font-size variables directly into colors.css and typography.css to preserve familiar defaults.
Organized CSS by component: one file per component, one unique root class, no cross-component overrides – no @scope or web components required.
Replaced media-query-heavy responsive layouts with CSS Grid auto-fit + minmax and grid-template-areas, reducing breakpoint count.
Used esbuild (static Go binary) for production bundling with @import and native nested selectors in development, no PostCSS or Node build chain.
Primary migration drivers: Tailwind v2’s 2.8MB unbuilt CSS file, inability to use grid-template-areas or other “weird stuff”, and mixed vanilla+Tailwind codebases becoming hard to maintain.
Hacker News Comment Review
Core debate: Tailwind critics argue its proponents never learned CSS past a junior level and discard cascading and DRY principles; defenders say poor outcomes reflect the developer, not the tool.
A recurring practical alternative mentioned is CSS Modules, which auto-generates unique class names and eliminates cascade conflicts without Tailwind’s readability and DevTools debugging costs.
Hybrid usage (Tailwind + Svelte/Vue scoped styles via @reference "tailwindcss") emerged as a middle path that limits template pollution while keeping utility convenience.
Notable Comments
@jakubmazanec: Names the real Tailwind sticking point – no need to invent BEM class names – which the article’s component convention does not fully solve.
@simonreiff: Notes Tailwind’s production purge/optimization is a concrete feature lost when switching to hand-rolled custom properties with full palettes shipped.
