In 2013, Facebook released React — a JavaScript library that would fundamentally reshape how web applications are built. A decade later, React is used by roughly 40% of professional developers, according to Stack Overflow’s 2024 survey, and powers the front-ends of Facebook, Instagram, Netflix, Airbnb and millions of smaller applications. It is the dominant paradigm. But a quiet rebellion is brewing in the web development community, led not by a new framework that promises to be faster or more elegant than React, but by a philosophy that questions whether we need JavaScript-heavy single-page applications at all.
The Complexity Tax
Modern web development, particularly in the React ecosystem, has accumulated a staggering amount of complexity. A typical React project in 2025 involves not just React itself but a state management library (Redux, Zustand, Jotai), a routing library, a server-state synchronisation library (React Query, SWR, or the increasingly complex Next.js data fetching patterns), a CSS-in-JS solution or utility framework (Tailwind), a build toolchain (Vite, Turbopack, or the older Webpack), TypeScript for type safety, and an ever-growing number of linting, formatting and testing dependencies. The result is an application whose dependency tree often contains thousands of packages before a single line of application logic is written. The popular create-react-app starter, which Meta officially deprecated in 2024, installed over 1,400 dependencies. Even its lighter successor, Vite’s React template, starts with roughly 300 packages.
This complexity is not free. It manifests in slow build times, difficult debugging, constant dependency churn, steep learning curves for new developers and a growing maintenance burden that falls disproportionately on small teams and solo developers. A 2023 survey by the State of JS found that 57% of React developers reported spending more time on configuration and tooling than on feature development. The term ‘JavaScript fatigue’ — coined nearly a decade ago — has not gone away. If anything, it has intensified.
HTMX and the Simplification Movement
HTMX is not a framework. It is a small JavaScript library — about 14 kilobytes minified and gzipped — that extends HTML with attributes allowing any element to make HTTP requests and swap the response into the DOM. Where React requires a client-side application that manages its own state, makes API calls and renders components, HTMX lets the server send HTML in response to user interactions, and the browser simply swaps it into place. The mental model is closer to how the web worked before single-page applications: the server is the source of truth, the browser is the rendering surface, and interactions trigger server requests that return new HTML fragments.
HTMX’s creator, Carson Gross, has been explicit about the philosophy: it is a reaction against the complexity of contemporary front-end development. The HTMX website features an essay titled ‘The Grug Brained Developer’ that argues for simplicity as a first-order value in software engineering. The approach has resonated. HTMX’s GitHub repository has accumulated over 40,000 stars — an extraordinary number for a library that deliberately avoids being a framework. It has been adopted by companies including Django’s parent organisation, and a growing number of startups are building their entire front-ends with server-rendered HTML, HTMX for interactivity and Alpine.js — another lightweight library — for client-side state when it is genuinely needed.
What HTMX represents is not a technical innovation but a philosophical one: the assertion that not every web application needs to be a complex single-page application, that the server-rendered model works well for the vast majority of use cases, and that the complexity of the React ecosystem — while appropriate for Facebook-scale applications with thousands of engineers and billions of users — is unnecessary overhead for most of the web. The rebellion against complexity is not going to displace React from the Fortune 500. But it is giving a growing number of developers permission to choose simpler tools for simpler problems.
