Tailwind CSS v4: novedades, rendimiento y guía de migración

35 milisegundos: tiempo de build incremental en Tailwind v3. En v4, la misma operación tarda unos 192 microsegundos.

Al principio no me lo creí — suena a copy de marketing. Pero tras migrar y ver el HMR pasar de 340 ms a 12 ms, quedó claro: Tailwind iba en serio.

Eso es el motor Oxide reescrito en Rust. No es placebo: cambias un padding y la página se actualiza antes de que parpadees. v4 también mueve la config a CSS, simplifica la instalación y actualiza utilidades (modificadores de opacidad, container queries, transforms 3D…).

Este artículo desglosa esos cambios y te deja una checklist de migración que puedes seguir paso a paso.

Motor Oxide: ¿por qué v4 es tan rápido?

¿Te ha pasado? Cambias un color, guardas y miras el navegador dos o tres segundos hasta ver el cambio. En proyectos grandes, los builds incrementales de Tailwind v3 pueden generar ansiedad — sobre todo con deadline encima.

El motor Oxide de v4 va directo a ese dolor. El equipo no parcheó el motor JS: reescribió el compilador en Rust desde cero. Decisión arriesgada, con beneficios reales.

¿Cuánto mejora el rendimiento?

Los benchmarks oficiales con el proyecto Catalyst son claros:

El último dato impresiona: si solo cambias HTML sin clases nuevas, v4 entra en microsegundos — imperceptible.

Datos de un proyecto en producción (500+ componentes):

Bajar el HMR de 340 ms a 12 ms cambia la experiencia de desarrollo. Antes había una pausa visible; ahora es casi instantáneo.

¿Qué hizo bien Oxide?

El núcleo es Rust + Lightning CSS. Rust aporta rendimiento, pero el cambio de arquitectura importa más:

Toolchain unificado. En v3, Tailwind dependía del ecosistema PostCSS: autoprefixer, cssnano, etc. v4 lo integra y solo usa Lightning CSS. Menos capas, más velocidad.

Detección inteligente de contenido. Antes configurabas content en tailwind.config.js. v4 lee .gitignore y el grafo de módulos y descubre archivos solo. Menos config, más rapidez.

CSS nativo. v4 usa @layer, @property, color-mix() y otras APIs modernas soportadas por el navegador, sin transformaciones extra en compile time.

No hace falta dominar cada detalle técnico. Lo que cuenta: builds más rápidos, menos configuración, mejor DX.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Configuración CSS-first: adiós tailwind.config.js

Es el cambio más grande de v4 y también el de mayor coste de migración.

Antes escribíamos en tailwind.config.js; ahora va al CSS con @theme. Al principio costó — años de config JS y de repente variables CSS. Tras usarlo un tiempo, encaja mejor con el modo de pensar CSS.

Migración de config: antes y después

Ejemplo mínimo — color primario:

// v3: tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: '#3b82f6',
      },
    },
  },
}

En v4, todo en CSS:

/* v4: app.css */
@import "tailwindcss";

@theme {
  --color-primary: #3b82f6;
}

Nota: primary pasa a --color-primary por reglas estrictas de prefijos.

Tabla de prefijos de variables

Al inicio parece verboso, pero no adivinas nombres: tamaños de fuente → --text-*.

Ejemplo de config más compleja

Config v3:

// v3: tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        brand: {
          light: '#f0f9ff',
          DEFAULT: '#0ea5e9',
          dark: '#0369a1',
        },
      },
      fontFamily: {
        display: ['Cal Sans', 'sans-serif'],
      },
      animation: {
        'fade-in': 'fadeIn 0.5s ease-out',
      },
    },
  },
  plugins: [
    require('@tailwindcss/typography'),
  ],
}

Migrado a v4:

/* v4: app.css */
@import "tailwindcss";

@theme {
  /* Colores */
  --color-brand-light: #f0f9ff;
  --color-brand: #0ea5e9;
  --color-brand-dark: #0369a1;

  /* Fuentes */
  --font-display: "Cal Sans", sans-serif;

  /* Animaciones */
  --animate-fade-in: fadeIn 0.5s ease-out;
}

/* Plugins */
@plugin "@tailwindcss/typography";

Cambios clave:

1. Colores aplanados: brand.light → --color-brand-light
2. Plugins con @plugin: sin require en JS
3. Sin sufijo DEFAULT: --color-brand es el default de brand

Modo oscuro

v3:

// v3
module.exports = {
  darkMode: 'class', // o 'media'
}

v4 usa media por defecto. Para class:

/* v4 */
@import "tailwindcss";
@variant dark (&:where(.dark, .dark *));

Aplica estilos dark cuando el elemento o un padre tiene .dark.

Detección de contenido

Antes especificabas archivos:

// v3
module.exports = {
  content: [
    './src/**/*.{js,ts,jsx,tsx}',
    './public/index.html',
  ],
}

v4 lee .gitignore, ignora exclusiones y escanea el proyecto. Estructuras raras: @source:

/* v4 */
@import "tailwindcss";
@source "../node_modules/my-ui-lib";

Ventaja: toda la config de estilos en un CSS, sin saltar entre JS y CSS. Inconveniente: curva de aprendizaje si venías de JS.

Instalación e integración: experiencia casi sin config

Instalar v3: tres paquetes, config, PostCSS, array content… No es terrible, pero en cada proyecto nuevo se repite.

v4 lo reduce al mínimo.

Instalación mínima

Con Vite, dos pasos:

# 1. Instalar
npm install tailwindcss @tailwindcss/vite

# 2. Una línea en vite.config.js
import tailwindcss from '@tailwindcss/vite'

export default {
  plugins: [tailwindcss()],
}

Y en el CSS:

/* app.css o index.css */
@import "tailwindcss";

Listo: sin tailwind.config.js, sin postcss.config.js, sin content.

Tres formas de integración

Vite (recomendado):

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

npm install tailwindcss @tailwindcss/vite

// vite.config.js
import tailwindcss from '@tailwindcss/vite'

export default {
  plugins: [tailwindcss()],
}

PostCSS:

npm install tailwindcss @tailwindcss/postcss

// postcss.config.js
export default {
  plugins: {
    '@tailwindcss/postcss': {},
  },
}

CLI:

npx tailwindcss -i input.css -o output.css --watch

La mayoría de proyectos modernos: Vite. PostCSS para migraciones legacy; CLI sin pipeline de build.

Cómo funciona la detección automática

v4 no pide content. Lee .gitignore, excluye node_modules, dist, etc., y busca clases Tailwind en el resto.

Requisito: estructura Node.js estándar. Plantillas fuera del árbol normal:

@import "tailwindcss";
@source "../templates";  /* Ruta manual */

Bonus: archivos nuevos sin tocar config. Antes actualizabas content por cada componente; ahora creas el archivo y funciona.

Cambios breaking y checklist de migración

Núcleo de la migración. La mayoría sigue patrones; hay herramienta oficial.

Modificadores de opacidad

El cambio con más impacto. v3:

<!-- v3 -->
<div class="bg-blue-500 bg-opacity-50">...</div>

v4 integra opacidad en el color:

<!-- v4 -->
<div class="bg-blue-500/50">...</div>

También texto y bordes:

<!-- Opacidad en texto -->
<p class="text-gray-900/75">...</p>

<!-- Opacidad en borde -->
<div class="border-red-500/30">...</div>

bg-opacity-* y similares: elimínalos; v4 no los soporta.

Utilidades renombradas

shadow → shadow-sm; shadow-sm → shadow-xs: nombres de tamaño más coherentes.

Valores por defecto

Pueden romper estilos visuales:

Color de border: v3 gray-200, v4 currentColor (sigue el color del texto).

<!-- v3: borde gris -->
<div class="border text-blue-500">Borde gray-200</div>

<!-- v4: borde sigue al texto -->
<div class="border text-blue-500">Borde blue-500</div>

Ring: v3 3 px blue-500; v4 1 px currentColor.

<!-- v3: ring azul 3 px -->
<button class="ring">...</button>

<!-- v4: ring currentColor 1 px -->
<button class="ring">...</button>

<!-- Efecto v3 -->
<button class="ring-3 ring-blue-500">...</button>

Checklist completa

En orden:

1. Actualizar dependencias

   npm install tailwindcss@latest @tailwindcss/vite@latest
   

2. Herramienta automática

   npx @tailwindcss/upgrade
   

Convierte @tailwind, opacidad, renombrados, etc.

3. CSS de entrada

   /* v3 */
   @tailwind base;
   @tailwind components;
   @tailwind utilities;

   /* v4 */
   @import "tailwindcss";
   

4. Migrar config a bloque @theme en CSS.

5. Plugins con @plugin:

   @plugin "@tailwindcss/typography";
   

6. Opacidad: busca bg-opacity, text-opacity, border-opacity.

7. Renombrados: shadow-*, rounded-*, flex-grow-*, flex-shrink-*.

8. Defaults: border y ring.

9. Regresión visual: tests visuales si los tienes.

La herramienta cubre ~80 %; el 20 % restante son defaults que solo tú puedes validar.

Novedades: Container Queries, transforms 3D y más

Además de rendimiento y config, v4 trae utilidades prácticas.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Container Queries nativas

Antes hacía falta plugin; ahora viene integrado:

<!-- Contenedor -->
<div class="@container">
  <!-- Responsive al ancho del contenedor -->
  <div class="@md:grid-cols-2 @lg:grid-cols-3">
    ...
  </div>
</div>

@container ≈ container-type: inline-size; @md: es breakpoint de container query. Similar a md:, con @ delante.

Ideal en librerías de componentes: el estilo responde al padre, no solo al viewport.

Utilidades 3D Transform

<!-- Perspectiva 3D -->
<div class="perspective-distant">
  <!-- Rotación eje X -->
  <div class="rotate-x-45">...</div>
</div>

<!-- Rotación eje Y -->
<div class="rotate-y-12">...</div>

<!-- Escala eje Z -->
<div class="scale-z-150">...</div>

Clases: rotate-x-*, rotate-y-*, rotate-z-*, scale-z-*, perspective-*, translate-z-*… Flips de tarjeta y menús 3D más sencillos.

Variante @starting-style

Con la regla CSS @starting-style, para el primer render:

<!-- De transparente a opaco al aparecer -->
<div class="starting:opacity-0 opacity-100 transition-opacity">
  ...
</div>

Animación de entrada sin JavaScript. Antes animate-fade-in custom; ahora una clase.

Variante not-*

Pseudo-clase :not():

<!-- Todos menos el último -->
<li class="not-last:mb-4">...</li>

<!-- Botones no disabled -->
<button class="not-disabled:opacity-100">...</button>

Más claro que trucos inversos tipo last:mb-0.

Gradient API ampliada

<!-- Gradiente cónico -->
<div class="bg-conic/from-red-500 via-yellow-500 to-blue-500">...</div>

<!-- Gradiente radial -->
<div class="bg-radial from-white to-transparent">...</div>

<!-- Modo de interpolación -->
<div class="bg-linear-to-r from-blue-500 to-purple-500 via-oklch">...</div>

via-oklch suaviza transiciones, sobre todo al cambiar espacio de color.

Conclusión

¿Merece la pena actualizar?

Si el proyecto sigue activo, sí. HMR de cientos de ms a ~12 ms ahorra tiempo cada día. CSS más pequeño y menos memoria — sobre todo en monorepos grandes.

El coste está en config y renombrados. npx @tailwindcss/upgrade automatiza lo repetitivo. En mi prueba, un proyecto mediano (200+ componentes) migró en medio día con pruebas.

Proyectos nuevos: v4 directo. Instalación mínima, detección automática, CSS-first — no hay motivo para quedarse en v3.

Compatibilidad: Safari 16.4+, Chrome 111+, Firefox 128+. Navegadores viejos: espera.

Acciones:

• Proyectos nuevos: v4
• Existentes: npx @tailwindcss/upgrade
• Revisa border y ring por defecto
• Problemas: documentación oficial de upgrade