The runtime cost: a new rule for every value
Bar A adds a rule for every new width (2 at the start, 7 after five moves); drag the slider by hand and it keeps growing, and each insertion makes the browser recalculate styles. Bar B's CSS text never changes, so it keeps one rule forever and only the --w variable changes.
CSS-in-JS libraries such as styled-components and Emotion let you write CSS inside JavaScript components and compute it from props; runtime versions generate and inject styles in the browser on every render, which costs time and clashes with Server Components, so newer zero-runtime tools extract the CSS at build time.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Using the mini styled() from the first example, create a Card (a div) whose border colour comes from a $tone prop ("info" → #1c7ed6, "warn" → #f59f00) and render one of each.
Rewrite Bar A from the second example so it keeps a single CSS rule however the width changes, without using CSS variables.
Explain it without notes
Describe step by step what a runtime CSS-in-JS library does when a styled component renders.
What is useInsertionEffect and why was it added?
Why does runtime CSS-in-JS conflict with React Server Components?
What is zero-runtime CSS-in-JS and what do you give up with it?
Preview
Console
Nothing logged yet.Expected console output
style tags at start: 2
style tags after 5 moves: 7