React has grown beyond its original promise and it's causing more harm than good

Original Article ↗ Hacker News Discussion ↗

Critiques of React’s growing complexity argue that a tool originally designed for managing UI state in rich web applications has expanded into an ecosystem—Next.js, routing, state management, SSR, build tooling—that is often misapplied to simple sites and proves hard to maintain. Many responders counter that React itself remains a relatively small, stable library and that most pain comes from how teams layer additional dependencies, misuse hooks, or skip core web fundamentals in favor of “React-only” skills. Alternatives like Svelte, Vue, Solid, HTMX, Astro, Remix, and traditional server‑rendered frameworks are frequently cited as better fits for simpler or SEO‑heavy projects, underscoring a broader theme: pick tools based on problem complexity rather than defaulting to React for everything.

Role of React and appropriate use

  • Many argue React is excellent for complex, stateful web applications, but a poor fit for simple or mostly static sites.
  • Several commenters emphasize that criticism like “bad for static pages” is mis-aimed: React was not designed for basic sites.
  • Some see React as the first JS UI model that feels well‑engineered for the web (one‑way data flow, “UI as a function of state”).

Complexity, churn, and ecosystem vs core

  • Repeated theme: the ecosystem (tooling, routing, CSS‑in‑JS, build systems, state libraries) churns far more than React’s core API.
  • Some say you can use React with just components, useState, and plain CSS; others counter that real‑world apps end up depending on many unstable tools.
  • Several people feel React and especially modern Next.js have become overcomplicated, with too many ways to do the same thing.

Performance and the virtual DOM

  • One side: React is “as fast as anything else” for typical apps; virtual DOM was a major practical improvement vs string‑based DOM updates and jQuery.
  • Other side: poorly structured React apps can feel slow (e.g., laggy inputs), and virtual DOM is not inherently faster than direct DOM manipulation—just a way to make “re-render everything” viable.
  • Some note early marketing oversold the performance angle, leading to lasting misconceptions.

State management and hooks

  • Hooks split opinion: many find them elegant and testable; others see useEffect/useMemo as new “footguns” replacing old class‑component quirks.
  • External state tools (Redux, sagas, RxJS) are often blamed for complexity; some advocate minimal global state or event‑driven patterns, which others warn can become untraceable.

Alternatives and framework choices

  • Svelte, Solid, Vue, Preact, Astro, Remix, Fresh, and htmx are mentioned as lighter, more focused, or more comprehensible options.
  • There’s a recurring “framework lifecycle” observation: tools start simple, gain features, become bloated, and are replaced by the next “small, fast” contender.

Developer skills & fundamentals

  • Multiple commenters report “React developers” who lack basic JS/DOM/CSS knowledge.
  • Some argue you should understand at least one layer below your abstraction; others say tools can still be used effectively without deep internals, though leaky abstractions (like regex or React) complicate this.