Migração do Linear para StyleX acelera navegação em 30%
A migração do Linear para StyleX, que tirou os aplicativos React da empresa do styled-components em mais de 1.000 pull requests, terminou no início de agosto de 2026, escreveu o engenheiro Kenneth Skovhus em 26 de agosto de 2026. O trabalho combinou um codemod determinístico, agentes de programação e revisão humana. A Linear diz que as páginas pesadas em visualização agora fazem de 20% a 35% menos trabalho na thread principal e que a navegação está cerca de 30% mais rápida em uma máquina intermediária, um produto mais rápido para os clientes sem uma reescrita.
Por que a Linear saiu do styled-components
A Linear tinha dois problemas com sua antiga biblioteca de estilos: velocidade e controle. O CSS-in-JS em tempo de execução faz o navegador gerar estilos e injetar regras de CSS enquanto o app renderiza, e a Linear sentiu esse custo com força depois de atualizar para a renderização concorrente do React 18, na época em que o styled-components entrou em modo de manutenção. Cody Olsen, da Sanity, lançou um fork otimizado que cortou 40% dos tempos de renderização da Linear, mas ele o chamou de último recurso.
O segundo problema era o encapsulamento. Padrões como styled(Button) facilitavam reestilizar um componente por fora, e depois de um redesign a Linear se viu perseguindo uma longa cauda de regressões de interface. O engenheiro Kenneth Skovhus escreveu que limites claros importam mais à medida que os agentes de programação contribuem mais para a base de código.
O que a Linear escolheu no lugar e por quê
A equipe definiu regras para a próxima biblioteca: geração de estilos em tempo de build, estilização à distância deliberadamente difícil, mesclagem previsível entre arquivos, bom suporte a React e manutenção ativa. Avaliou a maioria das opções de estilização para React. A alternativa mais próxima, o vanilla-extract, foi rejeitada pela API fragmentada e pelos arquivos de estilo separados.
O StyleX, biblioteca CSS-in-JS atômica e de código aberto da Meta, venceu. Ele move a geração de estilos para o tempo de build, emite classes atômicas pequenas e sem colisão e alimenta o Facebook, o Instagram e o WhatsApp na web. Mantém os estilos ao lado dos componentes, tem uma API pequena e oferece contratos de estilo com tipagem segura. O custo é a rigidez: seletores dependentes do pai, seletores globais e reestilização por wrappers ficam mais difíceis, e a Linear manteve CSS Modules como saída de emergência para seletores globais.
Como o codemod, os agentes e os engenheiros dividiram o trabalho
O trabalho começou com um codemod determinístico, e não com agentes. Skovhus criou o styled-components-to-stylex-codemod sobre uma grande suíte de testes, com agentes ajudando a ampliá-lo; ele tem um playground online e, segundo a InfoQ, já passa de 500 pull requests e de aproximadamente 100.000 linhas.
A equipe definiu primeiro as variáveis do StyleX e as primitivas compartilhadas, deu aos agentes escopos estreitos com um executor do codemod, exemplos, scripts de validação e uma lista de verificação, e migrou os componentes folha antes dos compartilhados. Os agentes muitas vezes travavam ao conferir diferenças visuais, como estados de hover e temas, o que exigiu muito teste manual até que dois modelos mais novos, o Fable e o Sol, fossem lançados no meio do projeto.
"Se estivéssemos começando esta migração hoje, nos apoiaríamos muito mais no Fable e no Sol para executá-la diretamente." Kenneth Skovhus, engenheiro da Linear
Como a Linear manteve a migração andando por meses
A Linear manteve o trabalho de produto enquanto os dois sistemas conviviam e usou ferramentas para manter as pessoas migrando. Um contador na barra de ferramentas do desenvolvedor mostrava quantos styled-components havia em cada página, um destacador mostrava quais componentes já tinham sido migrados e um bot sinalizava novos styled-components em pull requests. Regras do Oxlint agora impõem as novas convenções.
O gráfico de progresso mostra a curva. Os arquivos com styled-components eram 100% dos arquivos de estilo em React na semana de 8 de março de 2026, 49% em 7 de junho e 0% em 6 de agosto. Os novos arquivos com styled-components caíram de um pico de 22 na semana de 19 de abril para zero na maioria das semanas depois de 31 de maio.
O que a migração do Linear para StyleX entregou
Os resultados medidos são da própria Linear. A migração levou mais de 1.000 pull requests e cerca de cinco meses, terminando no início de agosto de 2026. A Linear relata de 20% a 35% menos trabalho na thread principal em páginas pesadas em visualização, navegação cerca de 30% mais rápida em uma máquina intermediária e nenhuma regra de CSS injetada durante uma mudança de página.
O que isso diz às empresas com grandes aplicações web
Para uma empresa de software, a tarefa aqui é trocar uma biblioteca central do front-end em uma base de código grande e ativa sem congelar o trabalho de produto. A resposta da Linear combinou três partes: um codemod determinístico para o grosso repetitivo, agentes com escopos estreitos para o resto e engenheiros para o julgamento e as verificações visuais. A própria visão da empresa é que os agentes fariam mais do trabalho hoje.
O mercado mais amplo se move do mesmo jeito. A InfoQ informa que o Cursor passou do Tailwind para o StyleX, e o podcast Syntax concluiu que a rigidez extra não é muito divertida para humanos, mas os agentes prosperam com ela.
Perguntas e respostas
Quanto tempo levou a mudança da Linear para o StyleX?
Levou cerca de cinco meses e mais de 1.000 pull requests. A Linear terminou no início de agosto de 2026, e Skovhus descreveu o projeto em 26 de agosto de 2026.
Por que a Linear escolheu o StyleX em vez do vanilla-extract?
O vanilla-extract oferecia extração estática e tipagem segura, mas a Linear achou sua API fragmentada e não gostou dos arquivos de estilo separados. O StyleX mantém os estilos ao lado dos componentes e tem uma API menor.
Os agentes de IA fizeram a migração?
Em parte. Um codemod determinístico fez a maior parte do trabalho repetitivo, os agentes cuidaram de tarefas com escopo definido e os engenheiros fizeram as verificações visuais até a chegada dos modelos Fable e Sol, no meio do projeto.
A visão da MOZGII
Como nós construiríamos
Este caso é um bom modelo para qualquer grande migração de código, porque a Linear não começou entregando o trabalho aos agentes. Escreveu antes um conversor baseado em regras com uma grande suíte de testes, usou agentes nas partes que o conversor não resolvia e manteve as pessoas no trabalho que as máquinas ainda fazem mal, como julgar se uma página está certa. Seguiríamos a mesma ordem.
Se estivéssemos conduzindo uma migração assim, começaríamos pela base compartilhada: os tokens de design e os componentes básicos que todo arquivo convertido deve usar. O conversor trataria os padrões comuns e recusaria o que não reconhece, para que os casos estranhos vão a um agente ou a uma pessoa em vez de serem convertidos errado. Os agentes receberiam uma tarefa pequena e bem definida por vez, com exemplos e um script que confere o resultado. Um contador visível e uma verificação em cada pull request impediriam que código no estilo antigo voltasse a surgir.
Isso falharia nas verificações visuais. O código pode compilar e passar nos testes enquanto um estado de hover ou um tema escuro fica errado, e a Linear viu os agentes sofrerem exatamente aí. Acrescentaríamos comparações de captura de tela para cada componente convertido e mandaríamos qualquer diferença para uma pessoa. A única métrica que acompanharíamos é a parcela dos arquivos de estilo ainda na biblioteca antiga, semana a semana, junto com os novos arquivos acrescentados no estilo antigo.
Depois, transformaríamos as regras de lint no padrão para código novo, para que o próximo redesign comece limpo.
Fontes
De onde vêm os fatos desta matéria.