Not because the dropdown was hard.
Because your React app has become a negotiation with the ecosystem, not a conversation with the browser.
If your stomach tightened reading that, you are not alone.
The Moment You Knew It Was Too Much
You were not trying to build a new UI platform.
You were trying to ship a screen that helps someone do their job.
A filter. A table. A detail view. A save button.
Then the requirements stayed the same, but the surface area exploded.
One click meant a component, a hook, a query layer, a cache key, a loading state, an error state, a state store debate, and a review thread about where the logic should live.
You started doing small work in a large way.
That is when you knew something was off.
The Tax Nobody Puts On The Ticket
React is not the enemy.
The invisible tax is what gets built around it.
The "responsible" stack grows until every feature carries a backpack.
More abstractions. More conventions. More glue. More files.
And once the app gets big, the cost is not runtime.
The cost is human.
You hesitate before refactoring because you know the ripples will be weird.
You ship larger chunks because running through all the UI states feels exhausting.
You stop touching certain screens because they have a smell you cannot name, but you can feel.
That is how complexity wins.
Not with a crash.
With friction.
What The Industrial Complex Actually Means
The word sounds dramatic, but the mechanism is boring.
Complexity creates jobs.
Complexity creates content.
Complexity creates dependency graphs where every new library has a reason to exist.
Nobody wakes up and says they want a fragile app.
They just keep choosing the option that signals seniority.
More layers feels like progress.
More layers also makes you afraid to change anything.
That is the part nobody advertises.
HTMX Feels Like A Shortcut You Are Not Allowed To Take
HTMX does something that feels almost rude.
It lets the server return HTML again.
You click.
The browser sends a request.
The server returns a small fragment.
The DOM swaps it in.
No client-side state store.
No hydration issues.
No duplicate validation logic on both sides.
No JSON shape ceremony between frontend and backend.
It is not magic.
It is the web behaving like the web.
The One Screen That Changed My Opinion
There is always one screen.
The one everyone avoids.
The one where the table has filters, pagination, and a detail drawer, and every small change breaks one more edge case.
We had that screen.
Every change felt like stepping into a room with fragile glass.
A small UI adjustment became a full-day task, because state and data fetching and view logic were all braided together.
So we tried something that felt irresponsible.
We rebuilt that screen with server-rendered HTML and HTMX swaps.
We did not change the design.
We did not change the backend rules.
We just changed who owned the UI flow.
The server did.
And the screen stopped fighting us.
A Real Example In Simple Markup
Here is the kind of thing that looks too easy until you ship it.
A search box updates rows without you touching a state store.
<input name="q"
hx-get="/loans"
hx-trigger="keyup changed delay:250ms"
hx-target="#rows"
hx-push-url="true"
placeholder="Search loans">
<table>
<tbody id="rows">
<!-- server renders rows -->
</tbody>
</table>Your endpoint returns only the table rows.
The browser swaps them into #rows.
Your code stays honest because the UI state is the URL and the HTML on the page.
The Architecture Is Almost Embarrassing
This is the entire mental model.
It is so plain that you feel like you must be missing something.
You are not.
Browser
|
| Request Page
v
Server Renders HTML
|
| User Action Triggers Request
v
Server Returns HTML Fragment
|
v
Browser Swaps Fragment Into TargetNotice what is missing.
A client-side state machine to mirror server truth.
A second validation layer that drifts from the first.
A fragile choreography of re-renders.
In most internal tools and product surfaces, those are the things that cause the slow bleed.
A Small Benchmark That Actually Matters
People argue about performance like the only thing that counts is CPU.
Most teams lose weeks to change-cost, not milliseconds.
Here is the comparison that hit us in the face.
| Change | React Typical Path | HTMX Typical Path |
| --------------------- | ------------------------------------ | ----------------------- |
| Add One Filter Field | Component, Hook, Query Key, UI State | Template, Handler |
| Fix A Validation Edge | Frontend Rule And Backend Rule | One Rule On Server |
| Debug Weird Behavior | Re-render Trace And State Hunt | Request, Response, HTML |This is not a claim that HTMX is always faster.
It is a claim that it keeps work small when the problem is small.
That is a different kind of speed.
Where HTMX Will Hurt You
If your product is a canvas app, a rich editor, or a highly interactive client-side workspace, HTMX will feel limiting.
You will want local state, optimistic updates, and complex client interactions.
HTMX is not trying to win that category.
It is trying to rescue the category where you are building forms, dashboards, workflows, admin screens, and data-heavy pages that mostly talk to a server anyway.
That is a massive category.
The Hybrid Move That Keeps You Safe
This is not a religion.
Keep React where it is truly needed.
Use HTMX where React is just an expensive way to re-create the browser.
The best part is the psychological shift.
You stop treating every screen like a front-end application.
You start treating it like a web page that can be upgraded.
That mindset removes fear.
Fear is the real cost center.
The Challenge That Changes Everything
Pick the one screen your team avoids.
Rebuild it with server-rendered HTML and HTMX swaps.
Keep the same UI.
Keep the same rules.
Then measure something real: file count changed, bugs introduced, time to add one more field, and how often you felt lost.
If the number gets smaller and your brain feels calmer, you just learned the secret.
The React Industrial Complex does not hate HTMX because it is bad.
It hates HTMX because it makes the work look simpler than it is supposed to be.