Tailwind CSS v4.0 Beta 1

Original Article ↗ Hacker News Discussion ↗

What Tailwind Is and How It’s Used

  • Seen as “a new form of CSS for the component age,” not a full design system but a tool to build one.
  • Core idea: reuse via template/JS components rather than custom CSS classes; @apply is for small, simple cases.
  • Many use Tailwind in a hybrid way: utilities for unique sections (headers/footers), plus semantic component classes (e.g., buttons) or libs like DaisyUI on top.
  • Others prefer scoped CSS (Svelte, CSS modules, styled components) and only drop to Tailwind or custom CSS for specific needs (e.g., animations).

Utility Classes vs Traditional / Native CSS

  • Fans argue utility classes:
    • Make iteration much faster since style is co-located with markup.
    • Avoid cascade/specificity bugs and “spooky action at a distance.”
    • Encourage consistent design via a shared scale for spacing, colors, etc.
  • Critics say:
    • It’s “utility classes taken too far,” better suited to componentized UIs than “real HTML.”
    • Native CSS with custom properties, clamp(), modern layout, and Stylelint can now solve most problems cleanly, without extra tooling.
    • Tailwind introduces dependency and upgrade churn compared to “future-proof” vanilla CSS.

Responsive Design, Dark Mode, and Layout

  • Supporters like breakpoint prefixes (lg:) and state variants (hover:, dark:) as far more ergonomic than raw media queries and manual dark-mode theming.
  • Others note modern CSS (clamp, flexible grids) greatly reduces media query needs and that swapping theme files with design tokens can handle dark mode elegantly.

Performance and Build Pipeline

  • Some question the focus on further speedups when Tailwind builds are already fast.
  • Others strongly value shaving tens of milliseconds to enable near-instant feedback, hot reload on every keystroke, and complex pipelines where many tools must all be fast.
  • Rust-based LightningCSS is noted as both a simplification (single binary) and a performance win.
  • Debate on real-world cost: some say Tailwind output can be smaller than hand-written CSS; others (including someone working on browser CSS perf) emphasize that parsing large bundles many times is the real cost.

Color System: Move to OKLCH and P3

  • OKLCH is recognized as part of a broader trend toward perceptual color spaces.
  • Proponents: numbers map better to perceived lightness/chroma, easier programmatic manipulation, and support for wide-gamut (P3) colors.
  • Critics: great for interpolation and some visualization, but poor for directly specifying colors; legal value ranges are narrow near gamut edges, making manual work hard. Often, plain sRGB hex is argued to be more practical.
  • Tools for exploring OKLCH and support in modern browsers are mentioned.

Tooling, Installation, and Webdev Complexity

  • Some are put off that “Getting Started” begins with Vite and npm for something that “just helps with CSS.”
  • Responses:
    • Tailwind is a build-time CSS generator; a build step lets you ship only used utilities (e.g., ~10 KB vs the full multi‑MB framework).
    • A standalone CLI binary exists for projects that don’t use Node.
    • Vite is widely used; integrating with existing bundlers is convenient but optional.
  • Broader ranting and pushback about JS ecosystem churn, dependency rot, and whether modern frontend stacks are overcomplicated vs genuinely enabling powerful workflows.

Other v4 Notes

  • Container queries support is welcomed; some argue the contain property is equally or more important for correctness and performance. A contain utility has been added.
  • CSS‑first configuration and shared design tokens are praised for making Tailwind easier to mix with regular CSS, especially in component architectures and markdown-driven sites.
  • Many report Tailwind remains “fun” and productive even after years; others warn that the pleasant experience can erode once broader JS tooling and upgrades enter the picture.