StyleX vs Tailwind: qué elegir cuando programa la IA

En agosto de 2026 pasaron dos cosas con una semana de diferencia. Cursor quitó Tailwind de su producto. Linear anunció que se iba de styled-components.

Los dos aterrizaron en el mismo sitio: StyleX, la librería de estilos de Meta.

No es una casualidad de calendario ni una moda de Twitter. Es la primera vez que dos equipos de referencia en herramientas para programadores justifican un cambio de CSS con un argumento que hace tres años no existía: el código lo escribe un agente y el agente necesita que le lleven la contraria.

Aquí va lo que vas a encontrar en este artículo:

• Qué es StyleX y qué problema resolvió dentro de Meta antes de salir a la luz.
• En qué se parece y en qué no se parece a Tailwind, con el mismo componente escrito en los dos.
• Por qué un agente de código comete menos errores con StyleX, y por qué eso tiene que ver con el compilador y no con el gusto.
• Las cifras reales de la migración de Linear: más de 1.000 pull requests y lo que ganaron a cambio.
• Lo que cuesta cambiarse, que no es poco, y cuándo no merece la pena.

¿Qué es StyleX y por qué Meta se molestó en construirlo? ¶

StyleX es un compilador de estilos: escribes objetos de JavaScript y en tiempo de compilación se convierten en CSS atómico. No hay runtime que inyecte reglas mientras el navegador pinta. Lo que llega al usuario es un archivo .css estático.

Meta lleva poco más de seis años desarrollándolo, según el propio equipo en su blog. Nació para resolver el CSS de facebook.com, se convirtió en la forma por defecto de escribir estilos en las superficies web de la empresa y se liberó en diciembre de 2023.

Hoy es el sistema de estilos de Facebook, Instagram, WhatsApp, Messenger y Threads.

El problema que resolvía era muy concreto y lo cuenta Meta en su artículo de ingeniería sobre CSS a escala: miles de ingenieros tocando estilos en el mismo producto producían colisiones entre bundles y dependencias imposibles de seguir. Cuando dos equipos definen .card sin saberlo, gana el que cargue después. Y quién carga después depende del bundler, no de ti.

La solución fue el CSS atómico generado por compilador. Cada par propiedad-valor se convierte en una clase única y reutilizable, y las definiciones repetidas se deduplican en todo el producto. Meta cifra la reducción de bundle de CSS en torno al 80% frente a su aproximación anterior.

🔑 La idea de fondo de StyleX no es “CSS-in-JS otra vez”. Es que el CSS deje de ser un espacio global compartido donde el último que escribe gana.

La versión actual en npm es la 0.19.1, publicada en septiembre de 2026. El changelog de los últimos meses da una pista de por dónde va el proyecto: DevTools para Firefox y Safari, identificadores estables entre desarrollo y producción, y un paquete nuevo, @stylexjs/atoms, para estilos atómicos en línea.

¿En qué se diferencia StyleX de Tailwind si los dos generan CSS atómico? ¶

Los dos generan CSS atómico. Ahí se acaba el parecido.

Tailwind te da un vocabulario de clases que escribes como strings dentro del HTML. StyleX te da una API de JavaScript donde los estilos son objetos tipados que el compilador valida.

Mira el mismo botón escrito de las dos formas. Primero, Tailwind:

// Tailwind: los estilos son texto dentro de una plantilla
export function Button({ danger, ...props }) {
  return (
    <button
      className={cn(
        'flex items-center px-4 rounded-md bg-violet-600 hover:bg-violet-700',
        danger && 'bg-red-600'
      )}
      {...props}
    />
  );
}

Ahora StyleX:

import * as stylex from '@stylexjs/stylex';
import { colors } from './tokens.stylex';

const styles = stylex.create({
  base: {
    display: 'flex',
    alignItems: 'center',
    paddingInline: 16,
    borderRadius: 6,
    backgroundColor: {
      default: colors.primary,
      ':hover': colors.primaryHover,
    },
  },
  danger: {
    backgroundColor: colors.danger,
  },
});

export function Button({ danger, ...props }) {
  return <button {...stylex.props(styles.base, danger && styles.danger)} {...props} />;
}

Sí, StyleX ocupa más líneas. Guárdate esa objeción, que luego vuelve con otra cara.

Fíjate en el detalle que de verdad importa, que está en el ejemplo de Tailwind. Cuando danger es verdadero, el className acaba conteniendo bg-violet-600 y bg-red-600 a la vez. ¿Cuál gana? Depende del orden en el que esas dos reglas aparezcan en la hoja de estilos compilada. No del orden en el que tú las has escrito.

Por eso existe tailwind-merge. Es una librería entera dedicada a resolver a mano un problema que el sistema no resuelve solo.

En StyleX ese problema no existe. El último estilo que pasas a stylex.props() gana, siempre, y si pasas null la propiedad se elimina. La composición es determinista por diseño, no por convención.

La tabla que resume el reparto ¶

Tailwind v4 no se quedó quieto, por cierto. La versión actual es la 4.3, la configuración se mudó de tailwind.config.js a @theme dentro del CSS, y el motor reescrito en Rust dejó los rebuilds incrementales por debajo de los 10 milisegundos. En velocidad de desarrollo, Tailwind sigue siendo difícil de batir.

Curso gratis · paso a paso

Las barandillas no son solo para el CSS

El mismo principio, un nivel más arriba: el ciclo completo de SDD con OpenSpec sobre un proyecto real, con proposal, spec, diseño y tareas antes de que el agente toque una línea.

Entra en el curso gratis →

¿Por qué los agentes de código escriben mejor StyleX que Tailwind? ¶

Porque un agente no falla al escribir. Falla al inventar. Y StyleX hace que inventar sea un error de compilación.

Esta es la parte que explica el titular, así que vamos despacio.

Un modelo genera bg-slate-750. Es una clase que suena perfecta, sigue el patrón de Tailwind al milímetro y no existe. ¿Qué pasa? Nada. El build pasa. Los tests pasan. El botón sale sin fondo y tú te enteras tres días después en una captura de pantalla de soporte.

El mismo modelo genera backgroundColor: colors.slate750 en StyleX. TypeScript se queja antes de que el archivo se guarde. El agente ve el error en su propio bucle de verificación y lo arregla sin que tú intervengas.

Esa es toda la diferencia. No es que StyleX sea más bonito. Es que convierte un fallo silencioso en un fallo ruidoso.

Hay tres mecanismos que producen ese efecto:

1. Tokens tipados en vez de texto libre. defineVars devuelve un objeto con tipos. Un color que no está en el sistema de diseño no compila, así que el agente no puede meter un gris de su cosecha en la mitad de tus tarjetas.
2. Propiedades restringidas por el linter. El plugin @stylexjs/eslint-plugin bloquea los atajos de CSS como border o margin y obliga a la forma larga. Menos ambigüedad, menos margen para que el modelo improvise.
3. Composición sin sorpresas. El agente no necesita razonar sobre especificidad ni sobre el orden del bundle. Solo sobre el orden de los argumentos, que es lo que tiene delante.

💡 Si solo te llevas una cosa de este artículo: en un flujo con agentes, la herramienta que gana no es la que escribe más rápido, es la que verifica más rápido.

Y aquí es donde los datos ayudan. La encuesta de Stack Overflow de 2026 sitúa la adopción de herramientas de IA en un récord del 84%, mientras la confianza en su resultado cae al 29%, desde el 40% de 2024. Adopción altísima, confianza en mínimos.

Cuando desconfías del código que entra, lo que necesitas no es un generador mejor. Necesitas un verificador. Y el compilador es el verificador más barato que existe: no gasta tokens, no se cansa y no tiene un mal día.

Si te interesa esta idea de darle reglas explícitas al agente en vez de esperar que acierte, la hemos tratado desde otro ángulo en el post sobre DESIGN.md y los diseños con IA basados en reglas.

¿Qué pasa de verdad cuando un agente alucina con Tailwind? ¶

Pasa esto, y está documentado en el propio repositorio de Tailwind.

En enero de 2026 se abrió una discusión pidiendo skills oficiales de Tailwind v4 para agentes de IA. Reunió 63 votos a favor. El motivo que aparece en los comentarios es demoledor por lo cotidiano:

Los agentes instalan la versión 4 y después escriben el proyecto como si fuera la versión 3. Crean un tailwind.config.ts que v4 ya no usa. Alucinan clases de la sintaxis antigua.

¿Por qué? Porque los modelos han leído muchísimo más v3 que v4. La documentación de v3 lleva años en internet. La de v4 es nueva. El modelo elige lo que más ha visto, y lo que más ha visto está obsoleto.

Lo importante no es que el agente se equivoque. Es que nada se lo dice. Un tailwind.config.ts que no se lee no lanza ningún error: se queda ahí, silencioso, y tus tokens de diseño no se aplican nunca.

Tailwind es consciente del problema y está trabajando en ello, con skills y con mejoras en el IntelliSense que sugieren migraciones de v3 a v4. Pero fíjate en la naturaleza de la solución: documentación y contexto extra para el modelo. Es una capa que hay que mantener y que hay que cargar en cada sesión.

La aproximación de StyleX es distinta. No intenta que el modelo sepa más. Intenta que el modelo no pueda equivocarse sin que el build se entere.

Las dos estrategias son legítimas. Son la diferencia entre enseñar mejor y poner barandillas.

¿Qué ganó Linear al migrar más de 1.000 pull requests? ¶

Linear publicó los números, y son los más concretos que hay sobre la mesa ahora mismo.

La migración de styled-components a StyleX se completó a lo largo de más de 1.000 pull requests. Los resultados que reportaron:

• Entre un 20% y un 35% menos de CPU en el hilo principal dedicado a estilos en las páginas con muchas vistas.
• Alrededor de un 30% más de velocidad de ejecución en uno de sus entornos de prueba, lo que en máquinas de gama media se nota.
• La inyección de reglas CSS durante la navegación pasó de cientos a cero.

Ese último punto merece una explicación. CSS-in-JS en tiempo de ejecución significa que el usuario paga la generación de estilos y la inyección de reglas mientras el cliente renderiza. Con React 18 y el renderizado concurrente, ese coste empeoró. Cada navegación disparaba trabajo de estilos que el navegador tenía que atender antes de pintar.

Con StyleX ese trabajo ocurre en tu CI, no en el portátil de tu usuario.

Pero lo que más me interesa de la migración de Linear no son las cifras de rendimiento. Es lo que dijeron sobre por qué lo hicieron: el rendimiento fue el disparador, y lo que buscaban era tener contratos de estilo explícitos ahora que los agentes escriben cada vez más código. Más flexibilidad significa más formas de producir algo que funciona pero que viola cómo debería funcionar el código.

Y el cómo lo hicieron es la lección práctica que te puedes llevar hoy:

1. Un codemod determinista, que abrieron en styled-components-to-stylex-codemod, para la conversión mecánica.
2. Agentes de IA con alcance limitado para los casos que el codemod no cubría.
3. Reglas de lint propias y un verificador del repositorio consciente de los tipos para que las convenciones no se degradaran después.

Codemod para lo determinista, agente para lo ambiguo, linter para que no vuelva. Ese patrón de tres capas vale para cualquier migración grande que tengas delante, use StyleX o no.

⚠️ Un apunte sobre el codemod: no soporta createGlobalStyle, tiene soporte limitado de Flow y necesita configuración de adaptador para búsquedas dinámicas de tema. No es un botón mágico.

¿Qué es Astryx y por qué cambia el tablero? ¶

Esta es la pieza que convierte a StyleX de “opción interesante” en “apuesta de plataforma”.

En 2026 Meta liberó Astryx, su sistema de diseño de React, en beta y con licencia MIT. Lo había desarrollado en su interior durante ocho años hasta llegar a dar servicio a unas 13.000 aplicaciones internas.

Lo que trae:

• Más de 150 componentes accesibles, construidos sobre React 19.
• Tokens de diseño en CSS personalizables y varios temas, con modo oscuro.
• Estilos escritos con StyleX.
• Un CLI y un servidor MCP pensados a la vez para personas y para agentes.

Esa última línea es la novedad de verdad. Un agente que trabaja con Astryx no tiene que adivinar cómo se llama un componente, qué props acepta o cómo funcionan sus tokens de espaciado. Pregunta al servidor MCP, igual que tú escribirías un comando del CLI.

# Instalar el sistema de diseño y su CLI
npm install @astryxdesign/core @astryxdesign/theme-neutral @stylexjs/stylex
npm install -D @astryxdesign/cli

# Listar los componentes disponibles desde la terminal
npm run astryx -- component --list

El CLI lista y genera plantillas, imprime la documentación completa de un componente, construye temas y ejecuta codemods de migración entre versiones. Todo eso mismo está disponible por MCP.

Compara eso con la situación habitual: le pasas al agente un enlace a la documentación, cruzas los dedos y revisas lo que sale. Aquí el agente consulta la fuente de verdad en el momento en el que la necesita.

Si quieres profundizar en cómo se le da contexto de diseño a un agente sin que se invente la mitad, tenemos material sobre la skill frontend-design de Claude Code.

Antes de fiarte del agente

El compilador caza una clase inventada; lo demás lo cazas tú

Te llevas el ciclo anticaos para revisar lo que generan los agentes: pruebas con Playwright, casos Gherkin y adversarial review entre modelos.

Destripar el método →

Masterclass en directo · Acceso con Web Reactiva Premium · 15€/mes

¿Cuánto cuesta en realidad pasarse a StyleX? ¶

Bastante. Vamos con la parte que los hilos de Twitter se saltan.

El ecosistema no está ni cerca. Los recuentos públicos de npm sitúan a StyleX en torno a las 300.000 descargas semanales frente a los aproximadamente 12 millones de Tailwind. Es una diferencia de cuarenta veces, y se nota en todo: menos ejemplos, menos respuestas en foros, menos gente que ya ha pisado tu charco.

Renuncias a shadcn/ui. Esta duele. La librería de componentes de React más usada es Tailwind de nacimiento, y elegir StyleX significa quedarte fuera de su catálogo de más de cien componentes. Hay alternativas emergiendo, como registros de componentes estilo shadcn construidos con StyleX sobre primitivas de Base UI, pero es un ecosistema joven comparado con el original.

El build es más lento en desarrollo. StyleX compila con Babel. Tailwind v4 compila con un motor en Rust y hace rebuilds incrementales por debajo de los 10 milisegundos. En un proyecto grande con recarga en caliente, esa diferencia la sientes cada día.

Es más verboso. Vuelve a mirar los dos botones del principio. El de StyleX ocupa el triple.

Ahora, sobre ese último punto hay un contraargumento que me parece el más interesante de todo el debate: la verbosidad importa mucho menos cuando el que teclea es un agente.

Escribir treinta caracteres o escribir trescientos le cuesta lo mismo a un modelo. Lo que sí le cuesta es razonar sobre especificidad de CSS, sobre orden de bundles y sobre si bg-red-600 va a ganarle a bg-violet-600. La verbosidad de StyleX es explicitud, y la explicitud es justo lo que un agente aprovecha bien.

Dicho lo cual, tú sigues leyendo ese código. Y en una revisión de código a las siete de la tarde, trescientos caracteres son trescientos caracteres.

¿Deberías migrar tu proyecto a StyleX? ¶

Respuesta corta: casi seguro que no, todavía. Respuesta útil, en forma de tabla.

Hay una lectura intermedia que me parece la más sensata para casi todo el mundo, y es no elegir bando todavía.

Monta una pantalla real de tu producto con StyleX. Una sola. Con tus tokens, con tu tema oscuro, con tus estados de hover y focus. Pídele a tu agente que la extienda con dos componentes más y cuenta cuántas veces tienes que corregirle a mano.

Repite el ejercicio con Tailwind. Cuenta otra vez.

Ese número, medido en tu producto y con tu agente, vale más que cualquier hilo de opinión, incluido este.

¿Cómo empiezas con StyleX en veinte minutos? ¶

La instalación mínima con el plugin de Babel y el paquete principal:

npm install @stylexjs/stylex
npm install -D @stylexjs/babel-plugin @stylexjs/eslint-plugin

El primer archivo que deberías escribir no es un componente. Es el de tokens, porque es el que le pone barandillas a todo lo demás:

// tokens.stylex.js
import * as stylex from '@stylexjs/stylex';

// Estos tokens se convierten en variables CSS reales y tipadas
export const colors = stylex.defineVars({
  primary: '#7c3aed',
  primaryHover: '#6d28d9',
  danger: '#dc2626',
  surface: '#ffffff',
  text: '#111827',
});

export const spacing = stylex.defineVars({
  sm: '8px',
  md: '16px',
  lg: '24px',
});

A partir de aquí, cualquier estilo que escribas (o que escriba tu agente) consume esos tokens o no compila. Ni grises de más ni espaciados de cosecha propia.

Un par de APIs que conviene que conozcas antes de empezar, porque son recientes y la mitad de los tutoriales que encontrarás no las mencionan:

• La prop sx, disponible desde la 0.18.1, es azúcar sintáctico para {...stylex.props()} y quita bastante ruido del JSX.
• @stylexjs/atoms, que llegó con la 0.19.0, permite estilos atómicos en línea que compilan a la misma salida que stylex.create.
• stylex.defineConsts para valores que se resuelven en tiempo de compilación, como los breakpoints de tus media queries.

El roadmap hacia la v1.0.0 está abierto en GitHub y tiene un punto que conecta con todo lo que hemos hablado: archivos de contexto preparados para LLM. La propuesta pide documentación pensada para meterse directa en el contexto de un agente, con las reglas del linter, las APIs disponibles y la configuración de bundlers.

Documentación escrita para máquinas, en el roadmap oficial de una librería de estilos. Hace dos años eso no estaba en la lista de nadie.

Lo que este debate dice sobre las herramientas que eliges ¶

Durante quince años elegimos herramientas de frontend por cómo se sentían bajo los dedos. Por la ergonomía, por lo rápido que ibas del diseño a la pantalla, por lo poco que dolía el onboarding de alguien nuevo.

Tailwind ganó ese concurso con claridad y lo sigue ganando.

Lo que ha cambiado no es que Tailwind haya empeorado. Es que ha aparecido un criterio nuevo en la mesa que antes no puntuaba: cuánto se equivoca un agente con esta herramienta y cuánto tarda el sistema en decírselo. Es el mismo movimiento de fondo que recorre las tendencias de agentes de código de este año: delegas más, así que necesitas verificar mejor.

StyleX no gana porque sea mejor CSS. Gana en ese criterio concreto porque fue diseñado para un entorno donde miles de personas tocan los mismos estilos sin coordinarse. Resulta que ese entorno se parece muchísimo a trabajar con agentes.

Meta construyó barandillas para diez mil ingenieros. En 2026 esas mismas barandillas sirven para diez mil llamadas a un modelo.

¿Y tú? ¿Has medido alguna vez cuántas veces tienes que corregirle el CSS a tu agente, o sigues arreglándolo a mano sin contar?

TL;DR ¶

• 🚀 Cursor y Linear se pasaron a StyleX en agosto de 2026, y los dos citaron el trabajo con agentes como una de las razones.
• 🔧 La diferencia clave con Tailwind: los estilos son objetos tipados que el compilador valida, no strings que nadie revisa.
• ⚡ Linear midió entre un 20% y un 35% menos de CPU en el hilo principal tras migrar en más de 1.000 pull requests.
• 🎯 Una clase inventada por un modelo en Tailwind es un fallo silencioso; en StyleX es un error de compilación.
• 📚 Astryx, el sistema de diseño de Meta con más de 150 componentes, CLI y servidor MCP, es la apuesta real por un frontend legible para agentes.

Preguntas frecuentes sobre StyleX y Tailwind ¶

¿Qué es StyleX exactamente?
StyleX es una librería de Meta que define estilos como objetos de JavaScript y los compila a CSS atómico estático en tiempo de build. No hay runtime que inyecte estilos en el navegador. Es el sistema de estilos de Facebook, Instagram, WhatsApp, Messenger y Threads.

¿StyleX es más rápido que Tailwind?
En el navegador son comparables, porque los dos producen CSS atómico estático. En tiempo de build Tailwind v4 es más rápido gracias a su motor en Rust, con rebuilds incrementales por debajo de los 10 milisegundos, frente a la compilación basada en Babel de StyleX.

¿Por qué dicen que StyleX funciona mejor con agentes de IA?
Porque sus tokens son tipados y su composición es determinista, así que un valor inventado por el modelo produce un error de TypeScript o del compilador. En Tailwind, una clase inexistente es un string válido que no rompe el build y pasa desapercibido.

¿Puedo usar shadcn/ui con StyleX?
No de forma directa, porque shadcn/ui está construido sobre Tailwind. Existen registros alternativos de componentes estilo shadcn con StyleX sobre primitivas de Base UI, pero el catálogo es mucho menor que el original.

¿Tailwind está muerto?
Nada de eso. Tailwind mantiene alrededor de 12 millones de descargas semanales frente a las aproximadamente 300.000 de StyleX, sigue teniendo el ecosistema más grande del frontend y la versión 4.3 trajo mejoras sólidas. La conversación es sobre criterios nuevos, no sobre un relevo.

¿Qué versión de StyleX debo usar?
La 0.19.1, publicada en septiembre de 2026, es la última estable. Ten en cuenta que el proyecto aún no ha llegado a la 1.0, así que puede haber cambios de API entre versiones menores.

¿Cómo migro de styled-components a StyleX?
El codemod que Linear abrió en GitHub, styled-components-to-stylex-codemod, cubre la conversión mecánica de temas, variables CSS y envoltorios de componentes. Los casos que no cubre, como createGlobalStyle, hay que resolverlos a mano o con un agente supervisado.

¿Qué es Astryx y lo necesito para usar StyleX?
Astryx es el sistema de diseño de React de Meta, con más de 150 componentes y herramientas CLI y MCP para agentes. Usa StyleX por debajo, pero no lo necesitas: StyleX funciona por su cuenta.

¿StyleX funciona con Next.js o solo con React?
Funciona con React y tiene integraciones documentadas para Next.js, además de plugins para Babel, PostCSS, Rollup y un unplugin en camino. Hay soporte para frameworks que no son React mediante stylex.attrs.

¿Merece la pena migrar mi proyecto pequeño a StyleX?
Casi con seguridad no. La ventaja de StyleX aparece en bases de código grandes con sistemas de diseño propios y muchas manos, humanas o no, tocando los estilos. En un proyecto pequeño pagas el coste del ecosistema sin cobrar el beneficio.

Fuentes ¶

• StyleX en GitHub y su roadmap hacia la v1.0.0
• CSS at scale with StyleX, blog de ingeniería de Meta
• Styling Linear for the future with StyleX y el análisis técnico de Kenneth Skovhus
• Astryx, el sistema de diseño de Meta
• Discusión sobre skills oficiales de Tailwind v4 para agentes
• Encuesta de desarrolladores de Stack Overflow

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter