Tailwind, and why the classes look insane

You will open a file at work and find this:

<div className="flex items-center gap-3 rounded-lg border
                border-slate-200 p-4 hover:bg-slate-50">

The instinct — "that's inline styles with extra steps, we solved this in 2003" — is the correct instinct to have and the wrong conclusion to reach. Deal with the objection first, because until it is dealt with you will not use the tool honestly.

The problem Tailwind is solving

Traditional CSS asks you to name things. A component needs a style, so you invent .card__header--compact, put it in a stylesheet, and now you own a second file that must be kept in step with the first. Three things then go wrong, reliably:

• Naming cost. You spend real thought inventing names whose only purpose is to join two files together.
• Fear of deletion. You delete a component. Is its CSS still used anywhere? Nothing tells you. So it stays. Stylesheets only ever grow.
• Action at a distance. Changing .card to fix one page silently changes four other pages. CSS is a global namespace with no imports.

So what is a utility class

One class, one declaration. That's the whole model.

Those last two rows are the actual answer to "this is just inline styles." Inline styles cannot do hover, focus, media queries, or dark mode. Utility classes can, because they are real CSS rules. And the numbers are not free-form: p-4 comes from a fixed scale, so a codebase with fifty developers cannot accumulate padding values of 13px, 14px and 15px.

Install it — three steps

1. Install, in the Vite project from Lesson 1.

   npm install tailwindcss @tailwindcss/vite

2. Register the plugin. Tailwind now runs as part of Vite's pipeline — no separate PostCSS layer.

   vite.config.ts

   import { defineConfig } from 'vite'
   import react from '@vitejs/plugin-react'
   import tailwindcss from '@tailwindcss/vite'
   
   export default defineConfig({
     plugins: [react(), tailwindcss()],
   })

3. Import it in your CSS entry file. One line, replacing whatever is there.

   src/index.css

   @import "tailwindcss";

That is the entire setup. There is no config file until you want one — and when you do, it is CSS, not JavaScript:

@import "tailwindcss";

@theme {
  --color-brand: #8a3324;   /* now usable as bg-brand, text-brand, ... */
}

The part everyone gets wrong

Sooner or later you will repeat the same twelve classes on eight buttons and think: I should extract a CSS class for this.

Don't. In a component-based codebase you already have a mechanism for reuse, and it is better than a CSS class because it can carry behaviour and types as well as styling. Extract a <Button> component, not a .btn class. That is Lesson 3, and it is the reason Tailwind and React are so often seen together: Tailwind deliberately gives you no good abstraction mechanism, because the component is the abstraction mechanism.

Exercise

In src/App.tsx, delete everything in the returned markup and build a centred card using only utility classes. Target:

• white background, rounded corners, a thin grey border, a soft shadow
• padding inside; the card no wider than roughly 24rem; centred on the page
• a bold heading and a smaller grey paragraph under it
• the border changes colour on hover

Do not guess class names — use the search on tailwindcss.com/docs. Learning to find a utility fast is more valuable than memorising thirty of them.