Tailwind CSS v4.0 Beta 1

Original Article ↗ Hacker News Discussion ↗

Tailwind CSS v4.0 Beta prompts renewed debate over utility‑first styling versus “classic” CSS, with many praising Tailwind for faster iteration, responsive design ergonomics, and design-system-friendly defaults, while others argue that modern native CSS can now solve most of the same problems with less tooling. Commenters highlight v4’s technical changes—like a new high‑performance engine, a standalone CLI, and a shift to OKLCH and P3 colors—as important for both developer experience and bundle size. At the same time, there is persistent frustration with the broader JavaScript build ecosystem (Vite, npm, Node) and a recurring theme that Tailwind works best in a hybrid approach alongside scoped or traditional CSS.

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.