Moving on from React, a year later

Original Article ↗ Hacker News Discussion ↗

React-heavy single-page apps are increasingly being questioned as teams weigh their complexity, deployment overhead, and testing challenges against simpler server-rendered approaches. Commenters compare trade‑offs between Rails/Hotwire, HTMX-style “HTML over the wire,” and full SPAs, arguing over where business logic and state should live, how much JavaScript is really necessary, and when “fat clients” are justified for rich, offline-capable UIs. A recurring theme is that productivity and maintainability depend less on any specific framework and more on keeping the frontend as thin as the use case allows, avoiding duplicated logic, and choosing tools that match the app’s real interactivity needs.

Productivity and complexity: Rails vs React/TS

  • Many agree that duplicating logic across a JSON/GraphQL API and a React SPA slows development and increases risk.
  • Others contest the article’s “JS change costs 2× Ruby change” assumption, saying TypeScript + UI libraries make frontend changes fast, and Ruby’s dynamism/magic can be harder to work with.
  • General consensus: team familiarity and a single primary language/framework at a layer drive productivity more than language choice itself.

When SPAs are appropriate

  • Several argue fat clients shine when:
    • Multiple clients share the same APIs (web, mobile, queues, services).
    • Apps are highly interactive: editors, CAD/maps, video/photo tools, complex CRMs, real‑time dashboards, offline‑first, or sync‑heavy UIs (e.g., “Linear‑style” speed).
  • For CRUD‑heavy business apps and content sites, many claim SPAs are unnecessary overhead.

Server‑rendered HTML, HTMX, Turbo, LiveView

  • Many report success with Rails/Django/Symfony + Turbo/Stimulus, HTMX, Livewire, LiveView: simpler deployments, easier testing, fewer moving parts, no separate API for the web UI.
  • Critics say HTMX‑style architectures give worse DX/UX, messy templates, and poor discoverability, especially for frontend‑specialist teams.
  • Some emphasize that full‑page navigation and server‑rendered forms remain powerful and often “fast enough.”

Frontend ecosystem, overengineering, and churn

  • Repeated complaints about frontend teams building internal component libraries, multiple competing design systems, and constant framework churn that never pays off.
  • Others push back: overengineering and bad leadership exist everywhere, not just frontend; mature React stacks can be stable for years.

State management, APIs, and testing

  • Double state (frontend + backend) and custom client caches (e.g., Redux‑style query libraries) are seen as major sources of bugs and complexity.
  • Server‑rendered HTML is viewed as easier to test; LiveView‑style solutions draw criticism for being harder to test and reason about once nontrivial client state is added.
  • Strong separation between domain logic and views is widely recommended, regardless of stack.

Hybrid architectures and alternative stacks

  • Popular middle‑grounds:
    • Server‑rendered MPAs with “islands” of React/Vue/Preact.
    • Inertia‑style setups: React/Vue pages backed directly by server models instead of APIs.
    • Web Components + fetch(), Alpine.js, Stimulus, or small JS sprinkles.
    • Non‑JS frontends (Kotlin/JS, C++ backends with binary blobs to typed arrays) to avoid JS tooling pain.

Performance, devices, and UX

  • Some assert fat clients are here to stay, especially for AI‑heavy/dynamic UIs; others note median devices are weak, mobile networks are spotty, and JS SPAs often waste CPU/battery.
  • Agreement that you can build both very fast SPAs and very fast server‑rendered apps—but only with careful engineering.

High‑level takeaways

  • No consensus “winner.”
  • Broad agreement on: code is a liability; avoid unnecessary layers; choose SPA‑style complexity only when the interaction model truly demands it; otherwise favor simpler, server‑centric designs.