6 Months of Migrating from React to HTMX: Was It Worth It? (A Practical Review)

One of the hottest keywords currently burning through the frontend developer community is HTMX. The alluring promise that "you can build modern web apps without (or with very minimal) JavaScript" has naturally caught the attention of many.

Unable to resist my own curiosity, I decided to take the plunge. I took parts of our company's internal back-office system—which was originally built as a heavy React application—and completely rewrote them using HTMX. After actively running it in a production environment for the last 6 months, I want to share a very honest breakdown of the pros, cons, and realistic limitations I encountered.

This isn't just a summary of the official documentation; it's a collection of real, painful lessons learned during late-night debugging sessions. Keep reading!

1. Why Abandon Perfectly Good React for HTMX?

The biggest driving factor was 'complexity fatigue'.

Our back-office was a typical SPA (Single Page Application). To fetch a single piece of data and display it in a table, an exhausting number of steps were required:

• Create an API endpoint and ensure it responds with JSON.
• Call the data from the frontend using fetch or axios.
• Manage state using useState or useEffect.
• Handle loading states and render components.
• Handle errors (Error Boundaries or popping up Toast notifications).

Every time I needed to add a simple CRUD (Create/Read/Update/Delete) screen, I had to touch both the frontend and backend codebases. Just as I started thinking, "Shouldn't I just be able to render HTML on the server and throw it to the client?", HTMX caught my eye.

2. 3 Definite Pros Experienced After Adopting HTMX

Once I actually tore down the code, things definitely changed—especially regarding the developer experience.

An Overwhelming Reduction in Code (Especially Frontend)

This was the biggest impact. It felt like magic watching entire folders of frontend JavaScript files just vanish.

In React, code for state management (useState, Redux, Zustand, etc.) and API communication is mandatory. But with HTMX, you define the behavior directly within the markup (HTML) itself.

<!-- HTMX Implementation Example -->
<button hx-post="/api/users/123/approve"
        hx-target="#user-status"
        hx-swap="innerHTML">
  Approve
</button>

When you click the button, it sends a POST request to the server, and the server returns a snippet of HTML which HTMX automatically swaps into the #user-status element. Frontend state management becomes virtually unnecessary.

The Return of "Full-Stack" Development and Rapid Productivity

It felt like going back to the old PHP or JSP days, where the backend developer is the frontend developer. My primary backend stack is Python (FastAPI) and Go, and my workflow shifted to simply rendering HTML via template engines directly from the backend.

There was no need for meetings to align on frontend/backend API specs, and no need to constantly polish Swagger documentation. I just had the server draw the view I wanted and send it down. The perceived development speed for our back-office more than doubled.

Noticeably Lighter Bundle Sizes and Faster Loading Speeds

It goes without saying, but stripping away heavy React libraries and their massive ecosystems resulted in insanely fast initial load times. The HTMX library itself is only about 14kb (gzipped). Stuttering or lagging when accessing the back-office from low-end laptops or mobile networks completely disappeared.

3. However, Reality Bites (The Fatal Flaws)

Before shouting "This is a revolution! Let's rewrite everything in HTMX!", I have to share the fatal limitations I painfully realized during actual development.

Lack of Offline Support and Complex Client State Management

The core philosophy of HTMX is "Server-Source-Of-Truth". Every interaction assumes communication with the server.

The problem arises when the network is unstable, or when you need to implement UI that requires complex state changes purely within the browser without screen transitions (e.g., complex multi-step forms, or drag-and-drop interfaces where ordering changes in real-time before a final 'save').

In React, you'd just throw this into local state and manipulate it however you want. With HTMX, this process is incredibly clunky. Eventually, I had to slap on Alpine.js or vanilla JavaScript to solve these issues, making the code feel like tangled spaghetti once again.

The Absence of a Reusable UI Component Ecosystem

React's biggest weapon is its massive ecosystem. Libraries like MUI, Ant Design, and Radix UI allow you to drop in beautiful, accessible (a11y) components instantly.

In the HTMX ecosystem, I had to build these components from scratch. Even with a solid design system and Tailwind CSS, building complex components like a DatePicker or AutoComplete, or adapting them for server-side rendering, was sheer agony. (It made me truly appreciate the greatness of the open-source frontend ecosystem...)

Difficulty Expanding to Native Mobile Apps

What if our product needs to be released as a native iOS or Android app in the future? If we had built it with React (using a JSON API), we could just reuse the existing backend API for the mobile app.

However, the backend endpoints built for HTMX return HTML snippets, not JSON. A mobile app cannot parse and use HTML snippets effectively. Ultimately, you might face the nightmare of having to build a completely separate JSON API server for the mobile app, writing the logic twice. Fortunately, ours was a back-office tool that didn't need a mobile app, but for a B2C service, this is a very serious consideration.

4. Conclusion: Who Should Use HTMX, and When?

After 6 months of intense cohabitation, my conclusion is: "HTMX is not a silver bullet, but in specific areas, it is the ultimate tool that absolutely crushes React."

👍 I highly recommend HTMX if:

• You are building Admin panels or Back-office dashboards used primarily by staff.
• Your service lacks complex interactions and is mostly about viewing data and simple data entry.
• You have a small team lacking dedicated frontend developers, and backend developers need to churn out UI rapidly.

👎 I discourage HTMX if:

• You are building an app with extremely complex client interactions (like Trello, Figma, or Google Docs).
• Offline mode support is a mandatory requirement.
• You have plans to release a native mobile app (iOS/Android) in the near future.

Rather than blindly following development trends, it's crucial to objectively analyze the situation your team and product are currently in. I hope my experience provides a helpful clue when choosing the tech stack for your next project!