React is a JavaScript library for building user interfaces, originally developed at Facebook in 2013 and subsequently adopted by approximately every developer who has ever opened a terminal, whether they needed it or not.
React’s core innovation was the Virtual DOM — the insight that instead of updating the actual DOM directly, one should maintain a shadow copy of it in memory, diff the two trees on every state change, and then surgically apply the minimum necessary mutations. This is, on paper, elegant. In practice, it means your application maintains two DOMs where previously there was one, consumes memory where previously there was a paragraph tag, and reconciles trees at a frequency that would alarm a botanist.
“React’s virtual DOM was DESIGNED for this! Diff the state! Reconcile the tree! Only update what changed!”
— The Caffeinated Squirrel, proposing React to solve a problem that was solved by not re-rendering, The Copper List Rides Again
The Ecosystem
React is not merely a library. It is an ecosystem, which is a polite way of saying it is a library that requires forty-seven other libraries to do anything useful, each of which requires forty-seven others, recursively, until the node_modules directory achieves a mass sufficient to perturb nearby gravitational fields.
The installation of a React application via npm install has been observed to download more packages than there are atoms in a modest asteroid. Each package is maintained by a single developer who has moved on to Rust. The dependency tree is technically a directed acyclic graph, though “acyclic” is doing considerable heavy lifting in that sentence.
“No React. No virtual DOM. No reconciliation. No npm install with 847 transitive dependencies.”
— riclib, articulating what would later be codified as The Boring Technology Manifesto, The Databases We Didn’t Build
The Corporate Laptop Problem
The most devastating field study of React’s resource consumption was conducted, inadvertently, on the corporate laptops of every enterprise that has adopted it.
A typical corporate laptop in 2026 runs Windows 10, forty-seven Chrome tabs, an Outlook client that believes itself to be an operating system, and — crucially — three separate versions of React. One for the HR portal. One for the expense system. One for the “quick internal dashboard” someone built in 2019 and which has since achieved a kind of architectural immortality, in that no one can delete it and no one remembers why it exists.
The machines have 8GB of RAM. React is using 6GB of it. The remaining 2GB is split between Windows, Outlook, and the user’s will to live.
“You can’t fix the React apps. You can’t remove the seventeen Chrome tabs. You can’t give them more RAM. But you CAN make sure YOUR code doesn’t add to the problem.”
— The Caffeinated Squirrel, arriving at wisdom through the rejection of its own proposal, The Copper List Rides Again
The Proposal Pattern
In observed practice, the invocation of React follows a predictable social ritual known as The Proposal Pattern:
- A problem is identified (rendering, state, user interaction, or the passage of time)
- The Squirrel proposes React
- The problem is examined more closely
- The problem is solved without React
- The Squirrel proposes React for the next problem
This pattern has been documented across seven frameworks (React, Vue, Svelte, HTMX, Alpine, SolidJS, and briefly game engines), all of which were evaluated and found wanting. The framework ultimately used in production was HTMX — the one found wanting.
“I proposed adding a 42KB framework to avoid re-rendering, when the solution is to just… not re-render.”
— The Caffeinated Squirrel, experiencing what researchers classify as an unprecedented moment of stillness, The Copper List Rides Again
The Mass Hallucination
A growing body of scholarship suggests that modern frontend development operates under conditions best described as collective delusion. The symptoms include: the belief that a to-do list requires a virtual DOM, that twelve-millisecond database queries require a caching layer, and that twelve developers require four tribes.
“Modern development is a mass hallucination. SQLite is modern. It’s actively developed. It just doesn’t need a Medium article every week.”
— riclib, The Databases We Didn’t Build
The hallucination is sustained by a self-reinforcing cycle: React is used because companies use React, and companies use React because developers know React, and developers know React because bootcamps teach React, and bootcamps teach React because companies use React. At no point in this cycle does anyone ask whether the application — which checks account balances for twelve hundred users — needs a virtual DOM.
The Sports Car and the Field
The V3 Saga — a twenty-three-episode chronicle of fighting reactive signal frameworks — produced what may be the most concise diagnosis of React’s misapplication:
“Reactive signals are wonderful. But you’re using a sports car to plow a field.”
— The Lizard, The V3 Saga Final Chapter - Is It Fun To Fight Windmills
The field, in this metaphor, consists of: server-authoritative forms, SSE-streamed content, and one hundred forms that all work the same boring way. The sports car consists of: component lifecycle hooks, fiber architecture, concurrent rendering, suspense boundaries, and a reconciliation algorithm of considerable beauty and total irrelevance.
The saga ended with a toast:
“To boring technology!”
— The Caffeinated Squirrel, raising a tiny coffee cup, The V3 Saga Final Chapter - Is It Fun To Fight Windmills
Measured Impact
The following statistics have been observed in environments where React is deployed:
- 8GB RAM, 7.5GB React (corporate laptop, 2026)
- Three versions of React in one browser (HR portal, expenses, “quick dashboard from 2019”)
- 847 transitive npm dependencies for a form submission
- 2.3-second response time replacing a 47ms monolith (see: Gall’s Law)
- O(n²) payload growth from re-rendering everything the virtual DOM was supposed to prevent
- ~95% payload reduction achieved by removing React from the solution space
The Boring Technology Manifesto
The definitive response to React was not a competing framework but a refusal to participate:
IF A DATABASE EXISTS, USE IT. DON’T BUILD ONE.
IF A PROTOCOL EXISTS, USE IT. DON’T INVENT ONE.
IF CODE SERVED ITS PURPOSE, DELETE IT. DON’T MAINTAIN IT.— The Boring Technology Manifesto, The Databases We Didn’t Build
No React. No npm. No Docker. Just Go, SQLite, and stubbornness.
The bootblock couldn’t make the Amiga faster. It just had to not make it slower. The streaming renderer can’t fix the React apps. It just has to not add to the problem.
