Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

Original Article ↗ Hacker News Discussion ↗

Replacing React-style SPAs with HTMX and server-rendered HTML is presented as a compelling option for forums and CRUD-heavy sites, where most interactions are simple and payload size and time-to-interactive matter more than rich client-side state. Supporters highlight simpler stacks, better caching, and faster first loads, while critics argue HTMX scales poorly for complex, highly interactive UIs, leads to “attribute spaghetti,” and replays old problems from AngularJS-era approaches. Many conclude that HTMX works well when client-side state is minimal and pages are largely document-like, but React/Vue-style frameworks remain better suited for sophisticated app-like interfaces.

Scope of HTMX vs React/SPA Frameworks

  • Many see HTMX as ideal for server-rendered, content-heavy or CRUD-style apps (forums, admin UIs, forms, filters, pagination).
  • Others argue React/Vue/Solid-style frameworks are better for complex, highly interactive, stateful UIs (chat, notifications, editors, media players, DAWs).
  • Debate over whether modern frontend has “stabilized” on JSX; some say yes (React/Solid dominance), others point out major frameworks that don’t use JSX by default.

Performance, Traffic, and Caching

  • Pro‑HTMX comments: less JS shipped, faster first render, simpler caching of HTML fragments, better for low-end devices and high-traffic landing pages.
  • Critics claim React with SSR/hydration and CDNs can be efficient; heavy HTML fragment generation at scale (>10k req/s) can be costly for HTMX.
  • One practitioner found HTMX slow when returning large HTML responses for complex filters; switching to Alpine + partials reduced payload and felt faster.

State Management and “Spaghetti” Concerns

  • Detractors argue HTMX/attribute-driven approaches resemble Angular 1.0: scattered “codelets,” hard state management, and eventual “spaghettification.”
  • HTMX advocates counter that client-side state should be minimal; real state lives on the server, with HTML updates reflecting server truth.
  • Others report teams moving back to React after HTMX became hard to manage, while some say HTMX-based systems remain easier to maintain.

Interactivity Limits and Workarounds

  • Weak spots cited: rich in-page interactions (scrolling lists that update mid-scroll, text selection preservation, complex facet forms).
  • Suggested mitigations: DOM morphing extensions, out-of-band swaps, mixing HTMX with small JS components (Alpine, Web Components, Leaflet, etc.).
  • Some see HTMX as incomplete for “app-like” experiences; others recommend hybrid architectures (HTMX for most pages, React/Vue “islands” for heavy widgets).

Use Cases, Tooling, and Alternatives

  • Enthusiastic reports of HTMX powering full web apps and even PWAs; offline support requires service workers and heavy caching, which some consider convoluted.
  • Complaints about HTMX’s weak component composition and lack of Storybook-like tooling; suggestions include LiveView-style systems, Places.js, Pyview, or JS-first SSR frameworks.
  • Several emphasize there is no universal best tool; correct choice depends on interactivity level, state complexity, scale, and team skills.