Exercise 2: The Runtime-Cost Reason, and Why It's Structurally Unique in This Course — Possible Solution
====================================================================

THE CENTRAL, REAL TECHNICAL REASON FOR DECLINE
------------------------------
Per this chapter, "the central, real technical reason is runtime
cost. Classic CSS-in-JS libraries generate and inject styles at
runtime, in the browser, as components render — a genuine, measurable
JavaScript execution cost, and a genuine risk of a delay before styles
are actually applied (a real, documented 'flash of unstyled content'
in some setups)." Rather than the actual CSS being ready and available
before a page is even sent to the browser, classic CSS-in-JS has to
run real JavaScript code, IN THE USER'S OWN BROWSER, every time a
component renders, to compute and inject the actual CSS rules that
component needs — genuine extra work the browser has to perform on
every page load, with a real risk that content briefly appears
unstyled before that work finishes.

WHY THIS MAKES IT STRUCTURALLY DIFFERENT FROM EVERY OTHER PARADIGM IN
THIS COURSE
------------------------------
Per this chapter, "this is a direct, structural contrast with every
other paradigm this course has covered: Tailwind's own JIT (cssfw1-4)
generates CSS at build time, Bootstrap ships precompiled CSS, headless
libraries (cssfw1-6) ship zero styles at all. Classic CSS-in-JS is
genuinely the only paradigm in this entire course that does real
styling work in the browser, at runtime, rather than ahead of time."

Every other paradigm covered across this entire course produces its
final CSS BEFORE the browser ever needs it: Tailwind's JIT compiler
(cssfw1-4) generates the actual CSS file during the build process,
well before deployment; Bootstrap (cssfw1-5) ships an already-
compiled, ready-to-use stylesheet; headless libraries (cssfw1-6) ship
no CSS of their own at all, leaving styling entirely to whatever build-
time mechanism (typically Tailwind) the developer chooses. In every
one of these cases, by the time a real user's browser loads the page,
the CSS already exists as a finished, static asset — no additional
JavaScript computation is needed at that point just to determine what
the styles even ARE. Classic CSS-in-JS is the singular exception: it
defers that exact work until the browser is actually running the page,
making it the only paradigm in this course whose styling mechanism
imposes a genuine, measurable runtime cost on every single page load.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states the specific runtime mechanism precisely using the chapter's
own wording, and explicitly contrasts it against all three other named
paradigms individually (Tailwind/JIT, Bootstrap, headless libraries),
showing exactly why CSS-in-JS's own timing (runtime vs. ahead-of-time)
is the structural distinction the chapter is making.