Moving on from React, a year later

Original Article ↗ Hacker News Discussion ↗

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.