Moving on from runtime CSS-in-JS at scale
summary
GitHub runs on 4,000 presentational components that use runtime CSS-in-JS (styled-components / SX) and find big updates and server-side style collection painfully slow—style collection adds roughly 10% to server response time and streaming/suspense complicate injection. A prototype compiles styles out (Babel proof-of-concept, CSS-out.js) and alternatives like vanilla-extract or SWC/Rust plugins exist, but migration favors automation-assisted transforms (TS-morph) plus a VS Code autocomplete to preserve tokens; choose compile-time CSS for mixed teams, deeper JS for JS-native teams.
AI-written summary · about
chapters (10)
- 0:00Styling architecture challenges
- 1:53CSS-in-JS evolution 2015-2018
- 6:47Advantages and pitfalls of runtime CSS-in-JS
- 12:09SX prop at GitHub success
- 13:33Build-time CSS compilation
- 16:40JS tooling challenges at scale
- 18:28Modern CSS features
- 20:11Primer CSS autocomplete
- 21:56Migrating 4K components
- 24:44Choosing styling approach
related talks
15mCompilers in styling web UI
33mThe past, present and future of CSS-in-JS
25mStyled and SASSy: Choosing the Right React Styling Solution
31mUnique Value Proposition of CSSinJS and the Future
28mSee the Past, Present, and Future of CSS-in-JS
29mPreprocessors, Components, and CSS in JS or: How I Learned to Stop Worrying and Love the Website
43mPreprocessors, Components, and CSS in JS
39mUVP of CSSinJS and the future
