CSS-in-JS vs pre-compiled CSS for distribution
styling distribution trade-offs.
runtime cost and dynamic theming of CSS-in-JS versus cacheability and SSR simplicity of static CSS.
declaring one universally better with no mention of runtime or caching.
What's really being asked
This probes whether you evaluate styling delivery from the consumer's performance and integration perspective, not personal preference.
The full answer
Runtime CSS-in-JS, such as styled-components or Emotion, colocates styles with components, supports dynamic theming and prop-driven styles cleanly, and ships only styles for rendered components. The cost is a runtime library, style serialization during render, and added SSR and hydration complexity, which can hurt performance-critical apps. Zero-runtime CSS-in-JS like vanilla-extract or Linaria extracts styles to static files at build time, keeping authoring ergonomics while removing the runtime, at the price of more build configuration. Pre-compiled CSS files are framework-agnostic, highly cacheable by the browser and CDN, trivial to server-render, and have zero JS runtime cost. Their downsides are reliance on naming conventions to avoid collisions, theming through CSS custom properties rather than JS, and the risk of consumers shipping unused rules unless you support modular imports.
The mistakes people make
Saying CSS-in-JS is always cleaner without acknowledging runtime and hydration cost. Saying static CSS is always faster while ignoring theming and dead-code concerns. Ignoring SSR entirely. Forgetting that consumer bundle size and caching matter more than author convenience.
What usually comes next
How does each approach handle theming and dark mode. How do you tree-shake unused styles. How does each behave under SSR and streaming.
A concrete example
A performance-critical e-commerce site adopts your library; you ship pre-compiled CSS with custom properties for theming so styles cache across pages and render server-side with no JS cost, whereas a runtime CSS-in-JS approach would add per-render serialization and a hydration step on every page.
Interview question
For a performance-critical app that server-renders pages, what is the primary drawback of runtime CSS-in-JS versus pre-compiled CSS?
- a.It cannot express prop-driven or dynamic styles
- b.It adds a JS runtime and serialization cost plus SSR and hydration complexityCorrect
- c.It prevents the use of CSS custom properties for theming
- d.It is incompatible with browser caching of any kind
Why? this is the answer
Runtime CSS-in-JS serializes styles during render and complicates SSR and hydration, which static CSS avoids. It actually excels at dynamic styles and can use custom properties, so those options misstate its behavior.
Just read this? Test yourself on what you have been reading.
Read the original → blog.logrocket.com
- #css
- #css-in-js
- #design-systems
- #performance
- #styling
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on css — each one lists the topics its interview covers.
See open roles