Tailwind Setup, Config and the JIT Engine — Tailwind CSS & Modern CSS

Knowing what utility-first is does not help until Tailwind is actually wired into a project and producing CSS. Historically this was painful: early Tailwind shipped a giant pre-generated stylesheet and you 'purged' the unused parts in production, which meant development used one slow, bloated file and production used another — a split that caused classes to work locally but vanish after a build. The modern Just-In-Time (JIT) engine, now the default, exists to erase that split: it generates every class on demand the instant it appears in your source, in both development and production, with no separate purge step. Setting Tailwind up correctly means understanding the three moving parts — the content scanner, the config file, and the JIT engine — and how a single misconfigured path can make every class silently fail.

Analogy🏏Cricket

🏏 Think of it like cricket: Picture the Indian team walking out for a one-day international, and instead of a fixed batting line-up they could only bat using eleven pre-named 'specialist' players who each do exactly one thing. Traditional CSS is like inventing a brand-new specialist for every single delivery — a 'cover-drive-against-spin-in-the-43rd-over' player who is never reused. Just as a captain who must invent a fresh role for every ball would drown in selection paperwork, a developer inventing a new semantic class for every component drowns in naming and dead stylesheets. Just as a smart captain instead combines a small fixed set of reliable skills — defend, rotate strike, loft over mid-on — to handle any situation, utility-first combines a small fixed set of classes to build any design. The insight is that expressiveness comes from composition of primitives, not from an ever-growing vocabulary; a few dozen reusable skills cover infinite match situations, just as a few hundred utilities cover infinite layouts.