Tailwind CSS v4 landed with a proper bang. The CSS-first configuration model, the new high-performance Rust-based engine (Oxide), the slimmed-down setup story, on paper it looked like the framework had finally grown up. I’ve been watching UK development teams field this across client work and internal product builds for the better part of six months now, and the picture is more textured than the release notes let on. Some of it is genuinely impressive. Some of it will catch you off guard on a deadline.
What CSS-first configuration actually means in practice
The biggest philosophical shift in Tailwind CSS v4 in production is the move away from tailwind.config.js. Your design tokens, your theme extensions, your custom utilities, all of it now lives in a @theme block inside a CSS file. That’s a meaningful change, and for teams that already think in terms of design tokens, it clicks immediately.
In practice, I’ve seen two camps. Teams who had already invested in a structured token system (think semantic colour layers, spacing scales, type ramps) found the migration almost pleasant. The CSS custom properties that Oxide generates map directly onto what those teams already had in their heads. For them, the config file was always a slightly awkward intermediary, and removing it felt like cutting out a middleman.
The other camp, and this is most teams, if I’m honest, had their Tailwind config as a sprawling JavaScript object full of one-off values and plugin hacks accumulated across two or three years of client work. For them, the migration was a proper archaeology project. Not impossible, but not the afternoon job some blog posts implied. If your team is in that position, I’d strongly suggest reading up on building a proper design token pipeline with Style Dictionary before you try to port your config, it’ll save you repeating the same sins in a new format.
The Oxide engine: where the performance wins are real
Oxide is fast. That’s not marketing. A Tailwind v3 full build on a medium-complexity Next.js project I looked at was sitting around 1.8 seconds on a reasonably modern MacBook Pro. The same project with v4 and Oxide dropped to under 200 milliseconds. Incremental rebuilds in watch mode feel instantaneous, we’re talking sub-20ms on most saves.
For developer experience on UK agency projects where you’re sometimes running three or four services locally, that matters. The CPU headroom you get back is real. It’s the kind of change that makes you wonder why the JS ecosystem took so long to reach for Rust tooling, but here we are.
The output CSS story is also much cleaner. v4 generates far less bloat because the engine has a better understanding of which utilities are actually reachable from your source. On one SaaS dashboard project, the production CSS bundle dropped from 28kB (gzipped) to around 11kB without any additional purging configuration. That has a measurable knock-on effect on Core Web Vitals scores, particularly LCP on slower mobile connections, something UK teams building for diverse audiences across patchy 4G coverage genuinely need to care about.
Where the workflow still has rough edges
Right. Here’s the honest part that fewer people are writing about.
The IntelliSense extension for VS Code is not fully caught up. As of early 2026, autocomplete for custom theme values defined in @theme blocks is inconsistent. You get suggestions for core utilities reliably, but your own spacing tokens or custom colour ramps? Hit or miss depending on how you’ve structured the CSS file. For teams where designers and developers share the same editor setup, this creates friction. Not a dealbreaker, but annoying enough that I’ve seen junior devs quietly reach for inline styles when autocomplete fails them, which rather defeats the point.
Plugin compatibility is another honest headache. The v3 plugin API is gone. Anything you were pulling in that depended on plugin() or addUtilities() from the old API needs a rewrite or a replacement. Community plugins like @tailwindcss/typography and @tailwindcss/forms have official v4 versions now, but third-party ecosystem plugins are patchy. If your project has bespoke plugins for client-specific utility classes, budget time for a proper rewrite.
The @apply directive also behaves differently, specifically, it no longer works across component boundaries in certain CSS module setups. This caught several teams using CSS Modules alongside Tailwind for scoped component styles. The workaround exists (using CSS layers manually), but it’s not well documented and you’ll likely find it through Stack Overflow at 11pm rather than through the official docs.
Real decisions teams are making about adoption
From what I’ve seen across a handful of UK agencies and product teams, the pragmatic decision looks like this: new projects should start on v4 from day one. The clean-slate experience is good, the performance is genuinely better, and the CSS-first approach encourages better token discipline. The solo developers shipping Micro-SaaS products I’ve spoken to have taken to it particularly well, because they’re not dragging legacy config debt along with them.
Existing projects are a different calculation. If your v3 codebase is large, has custom plugins, and is actively generating revenue, the migration cost needs to sit in a proper sprint. Not a Friday afternoon. One London-based product team I’m aware of spent three weeks migrating a mid-sized B2B SaaS product, and they found bugs in their own component library that had been masked by v3’s slightly more permissive utility generation. So there’s an accidental quality benefit too, if you’re patient enough to find it.
For teams doing client delivery work where the project switches between Tailwind versions depending on the client’s stack, the cognitive overhead is real but manageable. The mental model for both versions is similar enough that context-switching is fine once you’ve internalised where your theme configuration now lives.
One thing that doesn’t get discussed enough: Tailwind v4’s cascade layer architecture makes it much more composable with existing CSS from third-party libraries or design systems. Teams integrating component libraries alongside Tailwind (say, Radix UI primitives with custom Tailwind-based styling) are finding fewer specificity conflicts. That’s a structural improvement that compounds over the lifetime of a project.
A note on tooling integrations and the broader stack
Tailwind v4 ships with first-class Vite integration, and if you’re on a Vite-based stack it’s probably the smoothest setup experience the framework has ever had. The Webpack integration exists but feels like a second-class citizen, which, given where the tooling ecosystem is heading, is probably fine. The GOV.UK style guidance aside, there’s no regulatory reason UK teams need to be on Webpack, but plenty of enterprise codebases still are, and those teams will need to factor that into their timeline.
For teams building on Next.js App Router, v4 works well but requires some care around server component boundaries and how styles are emitted. It’s not a blocker, but the Tailwind docs are still catching up to the App Router mental model. A few developers I know have ended up cross-referencing framework-specific community threads alongside the official docs to get the setup exactly right.
On the subject of integrations: if your team works with a wider development partner for backend and API work, you’re generally fine, Tailwind’s output is just CSS, so any backend stack is unaffected. Dijitul Developments is a good example of a UK shop building tight business logic integrations where the frontend stack is genuinely irrelevant to what they’re doing on the server side, which is worth remembering when scoping projects with mixed frontend and backend concerns.
The honest summary: Tailwind CSS v4 in production is a meaningful upgrade, not a cosmetic one. The performance gains are real, the CSS-first approach is architecturally sound, and the rough edges are all fixable with a bit of patience. Just don’t expect a frictionless migration if you’ve been on v3 for years. Plan properly, audit your plugins first, and start your next greenfield project on v4 from line one.
Frequently Asked Questions
Is Tailwind CSS v4 backwards compatible with v3 projects?
Not directly. Tailwind v4 introduces a new CSS-first configuration model and a rewritten plugin API that breaks compatibility with v3 config files and third-party plugins built on the old API. Migrating an existing v3 project requires manually porting your theme configuration into a @theme CSS block and rewriting or replacing any custom plugins.
How much faster is Tailwind CSS v4's build compared to v3?
The Oxide engine (Rust-based) makes full builds roughly 5-10x faster in typical projects, with incremental rebuilds in watch mode often dropping to under 20 milliseconds. Real-world results vary with project size, but the improvement is substantial enough to notice immediately during development.
Does Tailwind CSS v4 work with Next.js App Router?
Yes, but it requires some configuration care around server component boundaries and CSS emission. The Vite integration is the most polished path; if you’re on Next.js with Webpack, expect a slightly rougher setup experience until tooling documentation catches up.
What happens to @apply in Tailwind CSS v4?
@apply still works in v4, but it behaves differently in certain CSS Module setups, specifically, it can fail across component boundaries. Teams using CSS Modules alongside Tailwind for scoped component styles should test this early and be prepared to use manual CSS layer declarations as a workaround.
Should new UK projects start with Tailwind CSS v4 or stick with v3?
For new projects, v4 is the right choice: better performance, smaller output CSS, and a cleaner configuration model that encourages proper token discipline from the start. For existing v3 projects actively in production, migration is worthwhile but should be planned as a dedicated sprint rather than a quick upgrade.