The Future of CSS

Original Article ↗ Hacker News Discussion ↗

New CSS features such as native functions, anchor positioning, nesting, and layers are prompting both excitement and unease among web developers. Many welcome the ability to replace JavaScript and heavy frameworks with more powerful “vanilla” CSS, but others worry that the language is becoming an overcomplicated, quasi-programming language that’s harder to reason about, test, and keep interoperable across browsers—especially with Chrome’s outsized influence. Underneath the technical details is a broader tension over whether the web stack should keep evolving in place or be replaced by a simpler, more coherent alternative.

Enthusiasm for modern CSS

  • Many commenters say CSS has become a joy to use compared to a few years ago.
  • New features (grid, flexbox, nesting, @layer, :has(), variables, light-dark(), clamp(), etc.) make layout and theming far easier and reduce JS needs.
  • Some describe replacing significant JS with CSS, and building fast, responsive sites with careful HTML structure and modern layout tools.

Concerns about complexity and feature creep

  • Others feel CSS is becoming needlessly complex and “programming-language-like,” especially with functions and growing conditional logic.
  • Backwards compatibility means complexity can only increase; some wish CSS could be reduced to a simpler “good parts” subset.
  • The cascade and inheritance are still seen as core pain points; some prefer utility-class approaches or even HTML tables over modern layout systems.

Functions, Turing-completeness, and “CSS as a language”

  • Debate over whether functions belong in CSS:
    • Pro: similar ideas already exist in Sass; functions can reduce duplication and complexity, especially for patterns like gradients.
    • Con: risks turning CSS into an awkward programming environment; some worry about security, maintainability, and debugging once it’s clearly Turing-complete.
  • Several note that CSS is already effectively a programming language trapped in an old stylesheet syntax, lacking strong tooling like static type checking.

CSS vs JavaScript responsibilities

  • Some argue JS integration should be preferred for complex logic; others respond that CSS evaluation is lighter-weight and lower latency than JS.
  • There’s mention of the CSS Painting API and JS-based “reactivity” patterns, but also frustration that the platform hasn’t provided ergonomic native solutions for stateful UIs.

Interop, browser politics, and Chrome dominance

  • Discussion of the Interop program: intended to align browsers, but many showcased features are currently Chrome-only or Chrome-first.
  • Mixed views on whether Chrome is “bulldozing” standards versus genuinely pushing the platform forward.

Missing or desired primitives

  • Common wishes: better printing / paged media, native high-quality tooltips, customizable selects and date/time pickers, scoped CSS, easier corner/border shaping, automatic “relative corners.”
  • Some see these as more valuable than new decorative capabilities like advanced corner styles.

AI and developer workflow

  • Several people now lean on LLMs to write or translate modern CSS they don’t fully understand, treating CSS as something that’s fine as long as you rarely look at it directly.
  • Others caution against “vibecoding” frontends, arguing that user-facing UI still deserves careful, human-driven design.