(defcomp ()
  (~docs/page :title "On-Demand CSS: Killing the Tailwind Bundle"  (~docs/section :title "The problem" :id "problem"    (p (~tw :tokens "text-stone-600")      "Tailwind CSS generates a utility class for every possible combination. The full CSS file is ~4MB. The purged output for a typical site is 20-50KB. Purging requires a build step that scans your source files for class names. This means: a build tool, a config file, a CI step, and a prayer that the scanner finds all your dynamic classes."))  (~docs/section :title "The sx approach" :id "approach"    (p (~tw :tokens "text-stone-600")      "sx takes a different path. At server startup, the full Tailwind CSS file is parsed into a dictionary keyed by class name. When rendering a response, sx scans the s-expression source for :class attribute values and looks up only those classes. The result: exact CSS, zero build step.")    (p (~tw :tokens "text-stone-600")      "Component definitions are pre-scanned at registration time. Page-specific sx is scanned at request time. The union of classes is resolved to CSS rules."))  (~docs/section :title "Incremental delivery" :id "incremental"    (p (~tw :tokens "text-stone-600")      "After the first page load, the client tracks which CSS classes it already has. On subsequent navigations, it sends a hash of its known classes in the SX-Css header. The server computes the diff and sends only new rules. A typical navigation adds 0-10 new rules — a few hundred bytes at most."))  (~docs/section :title "The tradeoff" :id "tradeoff"    (p (~tw :tokens "text-stone-600")      "The server holds ~4MB of parsed CSS in memory. Regex scanning is not perfect — dynamically constructed class names will not be found. In practice this rarely matters because sx components use mostly static class strings."))))
