Tailwind CSS 4 to nie jest "kolejna wersja z kilkoma nowymi klasami". To przepisanie silnika i zmiana filozofii konfiguracji. Jeśli znasz v3 dobrze — ten artykuł jest dla ciebie. Zakładam, że wiesz co to JIT, jak działa `tailwind.config.js` i że nie musisz tłumaczyć co to `purge`.
Co nowego w Tailwind CSS 4
**CSS-first configuration — koniec z `tailwind.config.js`**
Największa zmiana: konfiguracja przenosi się do pliku CSS. Zamiast `tailwind.config.js` z obiektami theme, extend i plugins — teraz piszesz to bezpośrednio w CSS:
```css @import "tailwindcss";
@theme { --color-brand: oklch(55% 0.2 250); --font-display: "Inter", sans-serif; --spacing-18: 4.5rem; } ```
To diametralna zmiana DX. Dobra czy zła — zależy od projektu. Małe projekty zyskują (jeden plik konfiguracyjny mniej). Duże projekty z rozbudowanymi konfiguracjami i współdzielonymi presetami — tu jest ryzyko.
**Lightning CSS zamiast PostCSS**
Tailwind 4 korzysta z Lightning CSS jako parsera i transformatora. To narzędzie napisane w Rust, które jest wielokrotnie szybsze od PostCSS. W praktyce:
- Build cold start: z ~8s do ~1.5s na średnim projekcie - Watch mode: praktycznie natychmiastowy (poniżej 100ms) - Vendor prefixing: automatyczny, bez autoprefixera
Claim "5x szybszych buildów" jest realny — ale startując od projektu, który już miał OptimizedCSS i tree-shaking skonfigurowany, różnica to raczej 2-3x. Na projektach z dużą ilością custom CSS i dużym `content` — może być nawet więcej.
**Natywne warstwy kaskadowe (cascade layers)**
Tailwind 4 generuje CSS z natywnym `@layer`:
```css @layer theme, base, components, utilities; ```
To ma znaczenie przy integracji z zewnętrznymi bibliotekami UI. Wcześniej specyficzność Tailwinda mogła kolidować z stylami z Bootstrap czy MUI. Teraz warstwy dają jasny porządek kaskady — możesz nadpisywać styles bibliotek bez `!important`.
**OKLCH i paleta P3**
Nowa domyślna paleta kolorów używa OKLCH zamiast HEX/HSL:
```css --color-blue-500: oklch(62% 0.22 264); ```
OKLCH daje percepcyjnie równomierną przestrzeń kolorów — oznacza to, że `blue-400` i `blue-600` są naprawdę równoodległe wizualnie, nie tylko matematycznie. Dla displayów obsługujących P3 (większość nowoczesnych MacBooków, iPhonów) efekt jest zauważalny. Na starszych monitorach — niezauważalny.
Breaking changes z v3
Zanim wpadniesz w entuzjazm, tu jest lista rzeczy, które przestają działać:
**`border-border` znika**
W v3 `border` bez koloru dostawał `border-color: currentColor`. W v4 domyślny kolor bordera to szary (`--color-gray-200`). Jeśli masz setki komponentów z `border` i liczysz na stary behavior — będziesz musiał to przerobić lub nadpisać default.
**Zmiany w `ring-*`**
`ring` w v3 miał domyślny kolor i grubość. W v4 musisz jawnie podawać kolor:
```html
```
**JIT always-on (i inne tryby zniknęły)**
W v3 musiałeś włączyć JIT. W v4 jest tylko JIT — nie ma opcji "classic" engine. To dobra zmiana, ale jeśli masz projekt na bardzo starej wersji Tailwinda z wyłączonym JIT — migracja będzie wieloetapowa.
**Przestały działać niektóre pluginy**
Oficjalne pluginy (`@tailwindcss/typography`, `@tailwindcss/forms`) mają już wersje kompatybilne z v4. Ale nieoficjalne pluginy z npm — tu jest loteria. Sprawdź KAŻDY plugin zanim zaczniesz migrację.
Narzędzie migracyjne: `npx @tailwindcss/upgrade`
Tailwind dostarcza automatyczne narzędzie:
```bash npx @tailwindcss/upgrade@next ```
Co robi: - Konwertuje `tailwind.config.js` na `@theme` w CSS - Aktualizuje klasy, które zmieniły nazwę - Aktualizuje import w `postcss.config.js`
Co NIE robi: - Nie naprawia logiki komponentów zależnej od starych defaultów (np. `border-border`) - Nie migruje custom pluginów - Nie testuje czy wygląd po migracji jest identyczny
W MKM Labs przetestowaliśmy go na projekcie średniej wielkości (~80 komponentów). Automatyczna migracja zajęła 30 sekund. Naprawa wizualnych regresji — 3 godziny. Narzędzie robi dobrą robotę z mechaniczną zamianą, ale nie zastąpi QA.
Kiedy NIE migrować
Bądźmy konkretni. Nie migruj do v4 jeśli:
**Masz duże projekty z custom pluginami, które nie mają jeszcze v4-compatible wersji.** Sprawdź najpierw każdy plugin z npm, który używasz. Jeśli któryś nie ma wersji kompatybilnej — czekaj.
**Twój projekt jest na produkcji i nie masz pokrycia wizualnego testami.** Zmiany defaultów (border, ring) mogą powodować subtelne regresje, które wykryjesz dopiero gdy klient napisze "coś wygląda nie tak".
**Używasz Tailwinda razem z CSS Modules i masz skomplikowane warstwy kaskadowe.** Cascade layers v4 mogą wchodzić w kolizję z istniejącą architekturą CSS — testuj ostrożnie.
Podejście MKM Labs
Na nowych projektach startujemy z Tailwind 4. Na istniejących — migrujemy stopniowo: najpierw w środowisku stagingowym, z pełnym QA, bez pośpiechu. Nie ma presji — v3 nadal dostaje security patche.
Lightning CSS robi realną różnicę w DX przy dużych projektach — feedback loop w watch mode jest naprawdę szybszy. OKLCH to estetyczna poprawa, nie techniczna konieczność. CSS-first config wymaga przyzwyczajenia, ale po tygodniu jest naturalny.
Migruj, ale z głową. Nie dlatego że "v4 jest nowy", ale dlatego że realnie przyspiesza development workflow — gdy projekt jest na to gotowy.
Potrzebujesz podobnego rozwiązania?
Porozmawiajmy o Twoim projekcie
Pierwsza rozmowa jest bezpłatna. Opisz nam swój pomysł — odpowiemy w ciągu jednego dnia roboczego.
Umów bezpłatną rozmowę