Tailwind CSS 4 is not just an incremental update — it is a ground-up rewrite with a new engine called Oxide that delivers 10x faster builds and introduces a fundamentally different configuration approach. Instead of the JavaScript-based tailwind.config.js file that teams have been maintaining for years, Tailwind 4 moves to a CSS-first configuration using the @theme directive directly in your CSS file. This is the biggest change to the Tailwind developer experience since the framework was created, and migration requires careful planning.
The performance improvements are immediately noticeable. Our largest client project — a design system with over 400 components and 50,000 lines of Tailwind classes — saw build times drop from 4.2 seconds to 380 milliseconds. Hot module replacement in development went from perceptible lag to instant. These gains come from the Oxide engine being written in Rust and using a fundamentally different architecture for class detection and CSS generation.
Migration is straightforward for most projects but has a few gotchas. Custom plugins written for Tailwind 3 need to be rewritten as CSS-native extensions using @plugin. The theme() function in arbitrary values has been replaced with CSS custom properties — so theme(colors.blue.500) becomes var(--color-blue-500). If your project uses PostCSS plugins that depend on Tailwind's old AST, those will need updates too. We have migrated five client projects so far and the average migration takes about a day for a medium-sized codebase.
The new composable variants system is worth the migration alone. You can now define custom variants using @variant and compose them with existing variants in ways that were previously impossible without plugins. Combined with the native cascade layers support, Tailwind 4 finally solves the specificity wars that plagued complex component libraries. For teams building serious design systems, this release removes the last major pain points that made alternatives like vanilla-extract or Panda CSS tempting.