Linear StyleX-Migration: Navigation rund 30 % schneller
Die Linear StyleX-Migration, die die React-Anwendungen des Unternehmens in mehr als 1.000 Pull Requests von styled-components wegbrachte, war Anfang August 2026 abgeschlossen, schrieb Entwickler Kenneth Skovhus am 26. August 2026. Die Arbeit verband einen deterministischen Codemod, Coding-Agenten und menschliche Prüfung. Linear sagt, seitenlastige Ansichten verursachten jetzt 20 bis 35 % weniger Arbeit im Haupt-Thread, und die Navigation sei auf einem Mittelklasse-Rechner rund 30 % schneller: ein schnelleres Produkt für Kunden ohne Neuentwicklung.
Warum Linear von styled-components wegging
Mit seiner alten Styling-Bibliothek hatte Linear zwei Probleme: Tempo und Kontrolle. Laufzeit-CSS-in-JS lässt den Browser Stile erzeugen und CSS-Regeln einfügen, während die App rendert, und Linear spürte diese Kosten deutlich nach dem Upgrade auf das Concurrent Rendering von React 18, etwa zu der Zeit, als styled-components in den Wartungsmodus ging. Cody Olsen von Sanity lieferte einen optimierten Fork, der Linears Renderzeiten um 40 Prozent senkte, nannte ihn aber einen letzten Ausweg.
Das zweite Problem war die Kapselung. Muster wie styled(Button) machten es leicht, eine Komponente von außen umzugestalten, und nach einem Redesign jagte Linear einem langen Schwanz von UI-Regressionen hinterher. Entwickler Kenneth Skovhus schrieb, klare Grenzen seien wichtiger, je mehr Coding-Agenten zur Codebasis beitragen.
Was Linear stattdessen wählte und warum
Das Team setzte Regeln für die nächste Bibliothek: Stilerzeugung zur Build-Zeit, Styling aus der Ferne bewusst erschwert, vorhersehbares Zusammenführen über Dateien hinweg, gute React-Unterstützung und aktive Pflege. Es prüfte die meisten React-Styling-Optionen. Die nächste Alternative, vanilla-extract, schied wegen ihrer zersplitterten API und separater Style-Dateien aus.
StyleX, Metas quelloffene atomare CSS-in-JS-Bibliothek, gewann. Sie verlegt die Stilerzeugung in die Build-Zeit, erzeugt kleine, kollisionsfreie atomare Klassen und treibt Facebook, Instagram und WhatsApp im Web an. Sie hält Stile neben den Komponenten, hat eine kleine API und bietet typsichere Styling-Verträge. Der Preis ist Starrheit: Selektoren, die vom Elternelement abhängen, globale Selektoren und Umgestalten über Wrapper werden schwerer, und Linear behielt CSS Modules als Notausgang für globale Selektoren.
Wie Codemod, Agenten und Entwickler die Arbeit teilten
Die Arbeit begann mit einem deterministischen Codemod statt mit Agenten. Skovhus baute styled-components-to-stylex-codemod auf einer großen Testsuite, wobei Agenten beim Ausbau halfen; er hat einen Online-Playground und liegt laut InfoQ inzwischen bei über 500 Pull Requests und rund 100.000 Zeilen.
Das Team legte zuerst die StyleX-Variablen und gemeinsamen Primitive fest, gab Agenten enge Aufgabenbereiche mit einem Codemod-Runner, Beispielen, Validierungsskripten und einer Checkliste und migrierte Blattkomponenten vor geteilten. Bei der Prüfung visueller Unterschiede wie Hover-Zuständen und Theming blieben Agenten oft hängen, was viel manuelles Testen bedeutete, bis mitten im Projekt zwei neuere Modelle, Fable und Sol, erschienen.
„Würden wir diese Migration heute beginnen, würden wir uns viel stärker auf Fable und Sol stützen, um sie direkt durchzuführen." — Kenneth Skovhus, Entwickler bei Linear
Wie Linear die Migration monatelang am Laufen hielt
Linear führte die Produktarbeit weiter, während beide Systeme nebeneinander bestanden, und nutzte Werkzeuge, damit die Leute weiter migrierten. Ein Zähler in der Entwickler-Toolbar zeigte, wie viele styled-components auf jeder Seite lagen, eine Hervorhebung zeigte, welche Komponenten migriert waren, und ein Bot meldete neue styled-components in Pull Requests. Oxlint-Regeln erzwingen jetzt die neuen Konventionen.
Das Fortschrittsdiagramm zeigt die Kurve. Dateien mit styled-components machten 100 % der React-Styling-Dateien aus (Woche des 8. März 2026), 49 % am 7. Juni und 0 % am 6. August. Neue Dateien mit styled-components sanken von einem Höchstwert von 22 in der Woche des 19. April auf null in den meisten Wochen nach dem 31. Mai.
Was die Linear StyleX-Migration gebracht hat
Die gemessenen Ergebnisse stammen von Linear selbst. Die Migration brauchte mehr als 1.000 Pull Requests und rund fünf Monate und war Anfang August 2026 fertig. Linear meldet 20 bis 35 % weniger Arbeit im Haupt-Thread auf seitenlastigen Ansichten, eine um rund 30 % schnellere Navigation auf einem Mittelklasse-Rechner und null eingefügte CSS-Regeln bei einem Seitenwechsel.
Was das für Unternehmen mit großen Web-Apps bedeutet
Für ein Softwareunternehmen besteht die Aufgabe darin, eine zentrale Frontend-Bibliothek in einer großen, aktiven Codebasis zu ersetzen, ohne die Produktarbeit einzufrieren. Linears Antwort kombinierte drei Teile: einen deterministischen Codemod für den repetitiven Großteil, Agenten mit engen Aufgabenbereichen für den Rest und Entwickler für Urteil und visuelle Prüfungen. Nach eigener Einschätzung würden heute Agenten mehr der Arbeit tragen.
Der Markt insgesamt bewegt sich ebenso. InfoQ berichtet, Cursor sei von Tailwind auf StyleX umgestiegen, und der Syntax-Podcast kam zu dem Schluss, die zusätzliche Starrheit mache Menschen nicht viel Spaß, Agenten aber blühten darauf auf.
Fragen und Antworten
Wie lange dauerte Linears Umstieg auf StyleX?
Er dauerte rund fünf Monate und mehr als 1.000 Pull Requests. Linear war Anfang August 2026 fertig, und Skovhus beschrieb das Projekt am 26. August 2026.
Warum wählte Linear StyleX statt vanilla-extract?
Vanilla-extract bot statische Extraktion und Typsicherheit, doch Linear fand die API zersplittert und mochte keine separaten Style-Dateien. StyleX hält Stile neben den Komponenten und hat eine kleinere API.
Haben KI-Agenten die Migration durchgeführt?
Teilweise. Ein deterministischer Codemod erledigte den Großteil der repetitiven Arbeit, Agenten übernahmen abgegrenzte Aufgaben, und Entwickler die visuellen Prüfungen, bis mitten im Projekt die Modelle Fable und Sol erschienen.
Die Sicht von MOZGII
Wie wir es bauen würden
Dieser Fall ist ein gutes Vorbild für jede große Code-Migration, denn Linear übergab die Aufgabe nicht gleich an Agenten. Es schrieb zuerst einen regelbasierten Konverter mit einer großen Testsuite, setzte Agenten für die Teile ein, die der Konverter nicht bewältigte, und ließ Menschen die Arbeit machen, die Maschinen noch schlecht beherrschen, etwa zu beurteilen, ob eine Seite richtig aussieht. Wir würden dieselbe Reihenfolge wählen.
Würden wir eine solche Migration leiten, begännen wir mit dem gemeinsamen Fundament: den Design-Tokens und Basiskomponenten, die jede konvertierte Datei nutzen muss. Der Konverter erledigte die üblichen Muster und lehnte alles ab, was er nicht erkennt, sodass ungewöhnliche Fälle an einen Agenten oder einen Menschen gehen, statt falsch konvertiert zu werden. Agenten bekämen jeweils eine kleine, klar umrissene Aufgabe, mit Beispielen und einem Skript, das das Ergebnis prüft. Ein sichtbarer Zähler und eine Prüfung in jedem Pull Request hielten neuen Code im alten Stil fern.
Brechen würde es bei den visuellen Prüfungen. Code kann kompilieren und Tests bestehen, während ein Hover-Zustand oder ein dunkles Theme falsch aussieht, und Linear stellte fest, dass Agenten genau dort Schwierigkeiten hatten. Wir würden für jede konvertierte Komponente Screenshot-Vergleiche einführen und jeden Unterschied an einen Menschen geben. Die eine Kennzahl, die wir beobachten würden, ist der Anteil der Styling-Dateien, die noch auf der alten Bibliothek liegen, Woche für Woche, neben den im alten Stil neu angelegten Dateien.
Als Nächstes würden wir die Lint-Regeln zum Standard für neuen Code machen, damit das nächste Redesign sauber beginnt.
Quellen
Woher die Fakten dieser Meldung stammen.