What is Tailwind CSS

What it is

Tailwind gives you a constrained set of design tokens exposed as utility classes. You build UI by combining them in HTML, configure the design system in one file, and let the build purge everything unused so production CSS stays lean.

• Utility-first — style in markup, no custom class names
• Design tokens enforce consistent spacing, colour and type
• Build-time purge ships only the classes you use

When we reach for it

Tailwind fits projects that want to move fast with a consistent design system and no growing pile of bespoke CSS — landing pages, product UIs, and design-system components. It pairs especially well with React and Next.js work.

Trade-offs

Markup gets verbose — long strings of classes can hurt readability, mitigated with component extraction. There is a learning curve on the class vocabulary, and teams that prefer strict separation of concerns dislike styling in HTML. On this site we use Bootstrap 5, so Tailwind is a tool we apply where it suits, not a house default.

Why it matters

Tailwind CSS is a utility-first CSS framework that has become one of the most popular ways to style modern web applications. Instead of writing custom CSS or using pre-built components, you compose designs directly in your markup from small, single-purpose utility classes (like `flex`, `pt-4`, `text-center`). It matters because this approach dramatically speeds up UI development, keeps styling consistent through a design-system-in-config, and avoids the maintenance problems of large custom CSS files — you rarely leave your HTML, never invent class names, and the styles you are not using are stripped out at build time for a tiny final CSS bundle.

• A utility-first CSS framework for styling directly in markup
• Compose designs from small single-purpose classes rather than custom CSS
• Speeds development, enforces consistency, and produces tiny CSS bundles

Key characteristics

Tailwind provides a large set of utility classes mapped to a configurable design system (spacing, colours, typography, breakpoints), so you build UI by combining utilities in your HTML and customise the system in one config file. Its build step scans your markup and includes only the classes you actually use, so the shipped CSS stays small regardless of the framework's size. The main trade-offs are that markup becomes verbose with many classes (mitigated by component abstraction in your framework), and there is a learning curve to the utility names. In exchange you get speed, consistency, and no more battling a growing, brittle custom stylesheet.

• Utility classes mapped to a configurable design system in one config file
• Build step purges unused classes, keeping the final CSS tiny
• Verbose markup — mitigated by extracting components in your framework
• Trades a learning curve for speed, consistency and maintainability

When to use it

Tailwind suits teams and projects that value development speed and design consistency and are comfortable styling in markup — it is especially productive with component-based frameworks (React, Vue, Angular) where repeated utility strings are abstracted into components. It is less appealing to those who strongly prefer separating styles from markup, or for very small projects where its build tooling is more setup than needed. The decision is largely stylistic preference plus workflow: for fast, consistent UI work in a component framework, Tailwind is a highly productive default; for teams committed to traditional CSS separation, a different approach may fit better.

• Best for teams valuing development speed and design consistency
• Especially productive with component frameworks that abstract utility strings
• Less suited to those preferring strict style/markup separation
• A productive default for fast, consistent UI in a component framework