Migración de Linear a StyleX: navegación cerca de 30% más rápida
La migración de Linear a StyleX, que sacó las aplicaciones de React de la empresa de styled-components en más de 1.000 pull requests, terminó a principios de agosto de 2026, según escribió el ingeniero Kenneth Skovhus el 26 de agosto de 2026. El trabajo combinó un codemod determinista, agentes de programación con inteligencia artificial y revisión humana. Linear dice que las páginas con muchas vistas hacen ahora entre 20% y 35% menos trabajo en el hilo principal y que la navegación es cerca de 30% más rápida en un equipo de gama media: un producto más rápido para los clientes sin reescribirlo.
Por qué Linear dejó styled-components
Linear tenía dos problemas con su antigua biblioteca de estilos: velocidad y control. El CSS-in-JS en tiempo de ejecución obliga al navegador a generar estilos e inyectar reglas CSS mientras la app se renderiza, y Linear sintió ese costo con fuerza tras actualizar al renderizado concurrente de React 18, más o menos cuando styled-components entró en modo de mantenimiento. Cody Olsen, de Sanity, publicó un fork optimizado que redujo un 40 por ciento los tiempos de renderizado de Linear, pero lo llamó un último recurso.
El segundo problema era el encapsulamiento. Patrones como styled(Button) facilitaban cambiar el estilo de un componente desde afuera, y tras un rediseño Linear se vio persiguiendo una larga cola de regresiones de interfaz. El ingeniero Kenneth Skovhus escribió que los límites claros importan más a medida que los agentes de programación aportan más a la base de código.
Qué eligió Linear en su lugar y por qué
El equipo fijó reglas para la siguiente biblioteca: generación de estilos en tiempo de compilación, que modificar estilos a distancia fuera deliberadamente difícil, una fusión predecible entre archivos, buen soporte para React y mantenimiento activo. Revisó la mayoría de las opciones de estilos para React. La alternativa más cercana, vanilla-extract, se descartó por su API fragmentada y sus archivos de estilo separados.
Ganó StyleX, la biblioteca de CSS-in-JS atómico de código abierto de Meta. Lleva la generación de estilos al tiempo de compilación, produce clases atómicas pequeñas y sin colisiones, y da soporte a Facebook, Instagram y WhatsApp en la web. Mantiene los estilos junto a los componentes, tiene una API pequeña y ofrece contratos de estilo con tipos seguros. El costo es la rigidez: los selectores que dependen del padre, los selectores globales y el cambio de estilos mediante envoltorios se vuelven más difíciles, y Linear conservó CSS Modules como vía de escape para los selectores globales.
Cómo se repartieron el trabajo el codemod, los agentes y los ingenieros
El trabajo empezó con un codemod determinista y no con agentes. Skovhus construyó styled-components-to-stylex-codemod sobre una gran batería de pruebas, con agentes que ayudaron a ampliarlo; tiene un entorno de pruebas en línea y, según InfoQ, ya supera los 500 pull requests y unas 100.000 líneas.
El equipo definió primero las variables de StyleX y las primitivas compartidas, dio a los agentes alcances acotados con un ejecutor del codemod, ejemplos, scripts de validación y una lista de verificación, y migró los componentes hoja antes que los compartidos. Los agentes solían atascarse al revisar diferencias visuales como los estados hover y los temas, lo que implicó muchas pruebas manuales hasta que dos modelos más nuevos, Fable y Sol, salieron a mitad del proyecto.
«Si empezáramos esta migración hoy, nos apoyaríamos mucho más en Fable y Sol para hacerla directamente». Kenneth Skovhus, ingeniero de Linear
Cómo mantuvo Linear la migración en marcha durante meses
Linear siguió con el trabajo de producto mientras convivían los dos sistemas, y usó herramientas para que la gente siguiera migrando. Un contador en la barra de herramientas para desarrolladores mostraba cuántos styled-components había en cada página, un resaltador mostraba qué componentes ya estaban migrados y un bot señalaba los styled-components nuevos en los pull requests. Ahora, reglas de Oxlint hacen cumplir las nuevas convenciones.
La gráfica de avance muestra la curva. Los archivos de styled-components eran el 100% de los archivos de estilos de React en la semana del 8 de marzo de 2026, el 49% al 7 de junio y el 0% al 6 de agosto. Los archivos nuevos de styled-components bajaron de un máximo de 22 en la semana del 19 de abril a cero en la mayoría de las semanas después del 31 de mayo.
Qué logró la migración de Linear a StyleX
Los resultados medidos son de la propia Linear. La migración requirió más de 1.000 pull requests y unos cinco meses, y terminó a principios de agosto de 2026. Linear reporta entre 20% y 35% menos trabajo en el hilo principal en las páginas con muchas vistas, una navegación cerca de 30% más rápida en un equipo de gama media y cero reglas CSS inyectadas durante un cambio de página.
Qué les dice a las empresas con grandes aplicaciones web
Para una empresa de software, la tarea aquí es reemplazar una biblioteca central del front-end en una base de código grande y activa sin congelar el trabajo de producto. La respuesta de Linear combinó tres partes: un codemod determinista para el grueso repetitivo, agentes con alcances acotados para el resto e ingenieros para el criterio y las revisiones visuales. Su propia opinión es que hoy los agentes harían una parte mayor del trabajo.
El mercado en general va en la misma dirección. InfoQ informa que Cursor pasó de Tailwind a StyleX, y el podcast Syntax concluyó que la rigidez extra no es muy divertida para las personas, pero a los agentes les va muy bien con ella.
Preguntas y respuestas
¿Cuánto tardó la migración de Linear a StyleX?
Tomó unos cinco meses y más de 1.000 pull requests. Linear terminó a principios de agosto de 2026, y Skovhus describió el proyecto el 26 de agosto de 2026.
¿Por qué Linear eligió StyleX en lugar de vanilla-extract?
Vanilla-extract ofrecía extracción estática y tipos seguros, pero a Linear su API le pareció fragmentada y no le gustaban los archivos de estilo separados. StyleX mantiene los estilos junto a los componentes y tiene una API más pequeña.
¿Hicieron la migración agentes de IA?
En parte. Un codemod determinista hizo la mayor parte del trabajo repetitivo, los agentes se encargaron de tareas acotadas y los ingenieros de las revisiones visuales hasta que llegaron los modelos Fable y Sol a mitad del proyecto.
La visión de MOZGII
Cómo lo construiríamos
Este caso es un buen modelo para cualquier migración grande de código, porque Linear no empezó entregándoles el trabajo a los agentes. Primero escribió un convertidor basado en reglas con una gran batería de pruebas, usó agentes para lo que el convertidor no podía resolver y dejó a las personas en el trabajo que las máquinas todavía hacen mal, como juzgar si una página se ve bien. Seguiríamos el mismo orden.
Si lleváramos una migración así, empezaríamos por la base compartida: los tokens de diseño y los componentes básicos que todo archivo convertido debe usar. El convertidor resolvería los patrones comunes y rechazaría todo lo que no reconozca, para que los casos raros vayan a un agente o a una persona en lugar de convertirse mal. Los agentes recibirían una tarea pequeña y bien definida a la vez, con ejemplos y un script que revise el resultado. Un contador visible y una verificación en cada pull request evitarían que vuelva a colarse código del estilo viejo.
Fallaría en las revisiones visuales. El código puede compilar y pasar las pruebas mientras un estado hover o un tema oscuro se ven mal, y Linear vio que los agentes tropezaban justo ahí. Sumaríamos comparaciones de capturas de pantalla para cada componente convertido y enviaríamos cualquier diferencia a una persona. La métrica que vigilaríamos sería la proporción de archivos de estilos que siguen con la biblioteca vieja, semana a semana, junto con los archivos nuevos escritos en el estilo viejo.
Después convertiríamos las reglas de lint en el estándar para el código nuevo, para que el siguiente rediseño empiece limpio.
Fuentes
De dónde salen los datos de esta nota.