Learn Tailwind CSS - Quick Start — Installation & Basic Configuration

#Introduction

After understanding the architecture in episode 2, now it's time to get started quickly. Episode 3 walks you through installing Tailwind CSS via the three most common paths: the Tailwind CLI, the PostCSS plugin, and framework integration. You'll also write a minimal tailwind.config.js and run the development workflow with watch mode.

Which path you choose depends on your project. A static HTML project is fine with the CLI; a project with a bundler like Vite or a framework like Next.js usually uses PostCSS or a dedicated plugin. The end result is identical: a single static CSS file produced at build time.

#Installation Options

#Tailwind CLI

The simplest approach with the least bundler dependence:

npm install -D tailwindcss
npx tailwindcss init

Then builds are done with the -i flag for input and -o for output. This CLI is ideal for static HTML projects and quick prototypes. Note: in Tailwind version 4, the CLI is split into a separate @tailwindcss/cli package — always check the docs for the release you use.

#PostCSS Plugin

For projects that already use PostCSS — for example Vite or custom build tooling — install Tailwind as a PostCSS plugin:

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

The -p flag also creates postcss.config.js:

postcss.config.js

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
};

Tailwind then runs as part of the bundler pipeline, and autoprefixer adds browser prefixes automatically.

#Framework-integrated

Modern frameworks offer cleaner integrations. Next.js and SvelteKit use PostCSS as above; Vite has an official plugin; Astro also uses PostCSS. We'll break down per-framework integration in episode 18 — for now, just know they all still produce the same static CSS.

#Writing a Minimal tailwind.config.js

A minimal config needs just three main keys:

tailwind.config.js

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./index.html", "./src/**/*.{html,js,ts,jsx,tsx}"],
  theme: {
    extend: {},
  },
  plugins: [],
};

The most critical part is content. The more accurate the glob, the faster the scan and the smaller the generated CSS. Don't include folders you don't need, like node_modules or build directories.

#CSS File Structure and Development Workflow

#Input, Output, and Watch Mode

Create an input CSS file with the core directives:

src/styles.css

@tailwind base;
@tailwind components;
@tailwind utilities;

Then run a basic build:

npx tailwindcss -i src/styles.css -o dist/output.css

For development, use --watch so the build reruns automatically whenever a file changes:

npx tailwindcss -i src/styles.css -o dist/output.css --watch

The generated dist/output.css file is what you link in your HTML:

Linking the built CSS

<link rel="stylesheet" href="dist/output.css" />

The command npx tailwindcss -i src/styles.css -o dist/output.css --watch will accompany you throughout the series. In production, --watch is dropped and the build runs once on CI — a topic for episode 13.

#Conclusion

Episode 3 completes the practical setup: you know the three installation paths (CLI, PostCSS, framework), how to write a minimal config with the right content, and how to run the build workflow with watch mode.

Key takeaways:

• The Tailwind CLI is the simplest option for static projects.
• The PostCSS plugin is needed when your project already uses PostCSS.
• content determines which files JIT scans — keep it narrow.
• The @tailwind base, components, utilities directives must be in your input CSS.
• -i and -o set the input and output files.
• --watch enables automatic rebuilds for development.

Next, in episode 4, we'll enter the utility-first workflow: writing the most commonly used basic classes — typography, spacing, sizing, display, flexbox, grid, and state variants like hover and focus. It's time to write lots of markup.