We updated diffs in @linear. You can now preview images, SVGs, and GIFs, compare changes side by side, adjust opacity, and view sources. We’re still pushing to make diff reviews faster and nicer to use. Give it a try we’ve shipped a lot of improvements lately.

Thanks! Good question. Theming was the part of the migration I expected to fight us the most, and it turned into one of the more interesting pieces. Some context on why our setup is unusual. Linear themes are generated, not hand-authored: a custom theme is a few inputs (like base color, accent color, contrast), and from those we derive over a hundred color variables in LCH space. It goes further than most people expect: selection isn’t a background swap. When a row is selected, we regenerate the entire theme with the selected background as the new base, so labels, borders, and controls all re-derive against it. Same for focus, menus, and elevated surfaces, each scoped to its subtree by a nested ThemeProvider. That shape doesn’t fit StyleX’s built-in theming that well. Components author styles against ordinary stylex.defineVars tokens, but the tokens are placeholders: our ThemeProvider extracts the hashed custom-property names StyleX generated and injects one CSS rule per theme at runtime, scoped to the provider’s boundary. So essentially the setup is the same as before, just a lot more performant. Let me know if you have other questions.

Thanks! Good question. Theming was the part of the migration I expected to fight us the most, and it turned into one of the more interesting pieces. Some context on why our setup is unusual. Linear themes are generated, not hand-authored: a custom theme is a few inputs (like base color, accent color, contrast), and from those we derive over a hundred color variables in LCH space. It goes further than most people expect: selection isn’t a background swap. When a row is selected, we regenerate the entire theme with the selected background as the new base, so labels, borders, and controls all re-derive against it. Same for focus, menus, and elevated surfaces, each scoped to its subtree by a nested ThemeProvider. That shape doesn’t fit StyleX’s built-in theming that well. Components author styles against ordinary stylex.defineVars tokens, but the tokens are placeholders: our ThemeProvider extracts the hashed custom-property names StyleX generated and injects one CSS rule per theme at runtime, scoped to the provider’s boundary. So essentially the setup is the same as before, just a lot more performant. Let me know if you have other questions.

The reason I love working @linear is that this feature took 0 meetings, 0 RFCs, no A/B testing, no alignment with PM, no cross-team alignment, no H2 planning, no committees, it moved no KPI (as far as I am concerned). It felt good so we built it.

A few weeks ago I noticed that Linear got slower than it used to. Especially on the new Diffs feature, that we were getting ready to release, it was pretty bad. For days I was running profiles, staring at profiles, bisecting with agents from every direction. The pattern was clear - we accessed the DOM a ton, which blocked the main threads on style recalcs and layout for 10s or 100s of milliseconds over and over. I shipped dozens of PRs to get rid of those layout-causing calls, using pretext and whatever tricks the agents and I could come up with. It helped, but only a bit. I was getting desperate.

Imagine having all your company’s context in one system. Then teaching that system how to code. 💥 Issue → Code → Review → Land All from the same interface. Already, 30% of our triage issues are automatically fixed by the agent. And we are just getting started.