Detailed explanation
Tailwind CSS is a utility-first CSS framework: it provides small classes that each apply a focused styling rule. For example, flex sets display: flex, items-center aligns flex items on the cross axis, and text-center sets text alignment. You combine these utilities directly in HTML or component markup to build a design. Unlike a component framework, Tailwind does not normally give you a complete, predefined card or button; you choose the utilities that define its appearance.
With custom CSS, you might write class="card" in HTML and define its display, padding, background, and shadow in a stylesheet. With Tailwind, those choices appear as classes such as flex, p-4, bg-white, and shadow-md. Both approaches ultimately use ordinary CSS rules interpreted by the browser; Tailwind is not a different layout engine or inline styling. Its utilities reference a configurable design system, including spacing, colours, and typography. This helps developers reuse consistent values rather than repeatedly inventing slightly different ones, although custom CSS can achieve the same consistency through variables and conventions.
In a typical build setup, Tailwind scans project source files for utility class names and generates the corresponding CSS. Modern Tailwind generates utilities on demand; describing this simply as a 'JIT purge' mixes generation with older workflows that removed unused styles afterwards. Source detection also means dynamically assembled names such as bg-${colour}-600 may not be recognised: complete class names should appear in source or be explicitly included through supported configuration. Variants such as hover:shadow-lg apply styles for interaction states, while md:flex applies flex layout from the configured medium breakpoint upwards.
In the example, flex and justify-between arrange the heading and button, p-4 adds padding, and rounded-lg and shadow-md shape the card. hover:shadow-lg changes the shadow on hover, while transition enables transitions for supported properties. Tailwind can make implementation faster and reduce stylesheet switching, but long class lists can make markup harder to read. Reusable components help manage repeated patterns, and custom CSS remains useful for specialised rules. Interviewers look for this trade-off: Tailwind changes how you organise and author CSS, but it does not replace knowledge of layout, responsiveness, specificity, or accessibility.
Key points to remember
- Tailwind composes focused utility classes in markup instead of requiring a custom selector for every design.
- Utilities generate ordinary CSS; browser layout and cascade rules still apply.
- Configurable spacing, colour, and typography scales encourage consistent styling.
- Responsive and state variants, such as md:flex and hover:shadow-lg, express conditional styles.
- On-demand generation limits utility output, but verbose markup and source-detection constraints require care.
Common mistakes candidates make
- Calling Tailwind inline CSS or claiming it replaces the need to understand CSS.
- Describing modern Tailwind as generating every possible utility and then always purging unused ones.
- Constructing utility names dynamically without ensuring their complete names are detectable or explicitly included.
Likely follow-up questions
How is Tailwind different from inline styles?
Tailwind classes reference generated stylesheet rules, whereas inline styles put declarations directly in an element's style attribute. Tailwind also supports breakpoint and state variants, which a plain style attribute cannot express directly.
Can you use custom CSS alongside Tailwind?
Yes, Tailwind can coexist with custom stylesheets for specialised selectors, animations, or other requirements. When both style the same element, normal CSS cascade rules determine which declaration wins.
How do you avoid repeating long utility class lists?
In component-based applications, extract repeated structures into reusable components such as Button or Card. Tailwind also offers @apply for composing utilities into custom CSS rules, but reusable components usually handle repeated structure and behaviour more effectively.
Interview tip: Explain utility-first styling with two or three classes from the example, compare it with a custom .card rule, and finish with one benefit and one trade-off.