Last year I spent forty minutes setting up a React project for an internal admin dashboard. Just the boilerplate. Vite config, ESLint setup, Tailwind integration, React Router, TanStack Query because someone on Twitter said it was the right way to handle server state now. I hadn't written a single line of actual application logic yet and I already had twelve files open.
The dashboard needed to list records from a database, let you filter them, and update a status field. Three things. That's it.
I've been thinking about that moment a lot since then. Not because React was wrong exactly, but because the whole experience made me ask a question I probably should've asked earlier: what problem am I actually solving, and does my stack match that problem?
HTMX has been around since 2020, technically. Carson Gross built it on older ideas — intercooler.js, hypermedia, REST as it was supposed to work. But it's only in the last eighteen months or so that it's started showing up seriously in production codebases beyond hobby projects and blog posts. The HTMX GitHub repo crossed 40k stars. The State of JS 2024 survey showed a weird but real pattern: developers were increasingly marking "would not use again" next to React while usage stayed high. People are still using it, but the love is clearly cooling at the edges.
What HTMX actually does is conceptually simple enough to explain in one sentence: it lets HTML elements make HTTP requests and swap parts of the page based on the response. That's it. No virtual DOM, no component lifecycle, no client-side routing, no state management library to argue about. You write hx-get="/search" on an input and hx-trigger="keyup changed delay:300ms" and the results div updates. The HTML is the state. The server renders the HTML. You're done.
For a lot of use cases — the boring ones, the productive ones — that's genuinely enough.
Where Python comes in is almost too natural. Django and FastAPI are both excellent at rendering HTML fragments quickly. Django's template engine is underrated. FastAPI with Jinja2 is fast enough that you genuinely don't need to think about it for most traffic levels a small team will ever hit. You return an HTML fragment from your endpoint, HTMX drops it into the DOM, and the user sees something happen. No JSON serialization, no client-side deserialization, no React re-render cycle. The server does what servers are supposed to do: handle the data, decide what the UI should look like, send it down.
Miguel Grinberg wrote a good piece about this pattern in his Flask-HTMX tutorials and the core insight is something almost boring: web applications were server-rendered for a decade and a half and it worked fine. The SPA era solved real problems — but it also introduced an enormous amount of accidental complexity for cases that didn't need it.
I want to be fair here because the React discourse tends to go off the rails. React is not bad. React is very good at what it was built for. When you need rich client-side interactivity — collaborative editing, complex real-time interfaces, something like Figma or Notion — the component model, unidirectional data flow, and the client-side rendering approach make sense. The ecosystem is genuinely impressive. Next.js solved real deployment problems. React Server Components, once you get past the initial confusion about what they even are, are a real architectural idea worth understanding.
But most applications aren't Figma. Most applications are CRUD with some filtering. Most internal tools are forms, tables, and dashboards. Most freelance projects are e-commerce sites and appointment booking systems. And for all of those, the React stack asks you to carry a lot of weight that delivers nothing to your end users.
The JavaScript fatigue conversation has been happening for a long time — this 2016 post by Jose Aguinaga was funny eight years ago because it was accurate. The irony is it's somehow still accurate in 2026, just with different library names. Bundlers changed. State management evolved from Redux to Zustand to Jotai to whatever came after that. Server components got added to React in a way that made half the existing tutorials wrong. The amount of meta-knowledge required to set up a React project correctly — not even write application logic, just set it up — is genuinely unreasonable for a lot of teams.
Here's where I want to talk about something that doesn't get said enough in these discussions, which is the South Asian developer context specifically.
A lot of the conversation about frontend frameworks happens in the frame of a US/European developer with fast internet, a high-spec machine, and a client who doesn't care about performance as long as it looks modern. That context shapes the defaults. When Vercel or Netlify blog posts talk about bundle sizes and Core Web Vitals, they're often writing for an audience where a 300kb JS bundle is a minor annoyance. In Pakistan — Karachi, Lahore, Hyderabad, smaller cities — that's not a minor annoyance. Users on mobile data in Tier-2 cities are waiting for your SPA to hydrate and it shows.
Freelancers here mostly work on Upwork and Fiverr. A lot of the gigs are admin dashboards for small businesses, HR tools for local companies, basic inventory management systems. The budgets are not large. The timelines are tight. When a Pakistani developer can ship a fully functional admin panel with Django + HTMX in two or three days because there's no API layer to design, no client-side state to manage, no authentication token flow to wire up separately — that is a real, material productivity advantage.
I've talked to a few people doing final year university projects at HITEC, COMSATS, and similar universities around Sindh and Punjab. The React stack honestly overwhelms students who are still figuring out async/await. Watching someone understand HTMX in an afternoon and ship something that works by evening — that's not a small thing. There's something to be said for a technology that removes barriers to entry without sacrificing capability.
The local SaaS mindset here is also different. When someone in Karachi is building their first B2B software product, they're thinking about getting to paying customers fast, not about whether their architecture will scale to ten million users. Python with Django gives you ORM, admin panel, authentication, and a templating system in one package. Adding HTMX on top means you get reactive UI without the separate frontend deployment, the CORS configuration, the API versioning headache. For a solo founder or a two-person team, that simplicity is worth a lot.
The cases where I'd genuinely choose Python + HTMX are becoming clearer to me over time.
Internal tools are the obvious one. Any time a company needs a dashboard that only ten people use, building a full React SPA is an organizational tax, not a feature. The JavaScript bundle has to be maintained, the frontend dev has to know the API contract, someone has to manage the deployment pipeline. With server-rendered HTML and HTMX, it's just one application. One deploy. The developer who built the data model builds the UI. That's not unsophisticated, that's economical.
Small startups at the idea validation stage. If you're not sure whether your product has legs yet, spending three months building a polished React frontend before you talk to users is a bet you probably shouldn't be making. Django + HTMX lets a Python developer ship something users can click through in days. That's not a forever architecture, but it doesn't need to be.
Content-heavy sites with some interactivity. A blog that has a comment section, a search bar, a newsletter signup. HTMX handles those interactions cleanly. You're not pulling in a frontend framework for three interactive elements.
Where it gets harder is when you actually need rich client-side state. An application where the UI is the product — design tools, real-time collaboration, complex data visualization with local filtering and sorting that needs to feel instant. React and its ecosystem are genuinely better there. That's not a grudging admission, it's just accurate.
There's also the team dynamic angle that people underplay. A lot of teams have backend developers who know Python well and frontend skills that are functional but not deep. The React ecosystem requires either genuine frontend expertise or a willingness to do a lot of cargo-culting patterns from Stack Overflow. Server-side rendering with HTMX plays to Python developers' strengths and doesn't require a separate specialist. In markets where fullstack Python devs are easier to find and cheaper to hire than React developers, that matters organizationally.
Adam Johnson's work on Django + HTMX patterns and the HTMX documentation's own essays on hypermedia are worth reading if you want to understand the philosophy here rather than just the mechanics. The argument isn't "SPAs were a mistake." The argument is closer to: the web platform extended HTML to support interactivity through JavaScript, but maybe it should have extended HTML itself instead. HTMX is a bet on that idea. It's a small, focused library — around 14kb unminified — and it's deliberately unambitious in scope. It does one thing and expects HTML and HTTP to do the rest.
I keep coming back to something that's hard to articulate but feels important. There's a certain developer experience that React optimizes for — the experience of a developer inside the component, thinking in terms of state and props and effects. It's a powerful mental model once you internalize it. But it's a mental model you have to fully commit to, and it pulls a lot of complexity in with it.
HTMX optimizes for a different experience — the experience of building something where the server is in control and the browser is just displaying what the server says. That's a much older model. It maps onto how people actually think about data and business logic, which lives on the server. For a lot of developers, particularly those whose real expertise is in data, backend systems, and APIs, that model is more natural and requires less context-switching.
Neither of these is objectively better. They're suited to different problems, different teams, and different moments in a product's life.
What feels true in 2026, though, is that HTMX has earned its place in the conversation as a serious option for production work. It's not a protest against modern tooling. It's not nostalgia for PHP spaghetti. It's a genuine approach to building web interfaces that works well for a specific, large, and underserved category of application. The category that most of us are actually building most of the time.
I rebuilt that admin dashboard eventually. Three days with FastAPI, Jinja2 templates, and HTMX. No build step. No node_modules folder the size of a small country. Every developer on the backend team could read and modify the templates without learning a new paradigm.
It's still running. Nobody has asked me to rewrite it in React.
If you want to dig into the actual mechanics, the HTMX documentation is genuinely well-written and surprisingly short. For the Python side, full-stack-fastapi-template is a good starting point even if you swap out the React frontend for Jinja2. And this talk by Carson Gross at DjangoCon 2022 is the most coherent thirty minutes you'll spend understanding what HTMX is actually trying to do.
Connect With the Author
| Platform | Link |
|---|---|
| ✍️ Medium | @syedahmershah |
| 💬 Dev.to | @syedahmershah |
| 🧠 Hashnode | @syedahmershah |
| 💻 GitHub | @ahmershahdev |
| Syed Ahmer Shah | |
| 🧭 Beacons | Syed Ahmer Shah |
| 🌐 Portfolio | ahmershah.dev |
Top comments (69)
React is ALWAYS excessive! The article could have ended there. 🤣
Unfortunately, it's become a horrible trend, and the web has become filled with this library that constantly needs maintenance! You can do more stable and simple things with both Angular and Vue.js, but then people would have had to really study, whereas React can be learned in two days and is easy to use... no one cares if you then live only to maintain the thousands of libraries used to keep a project built with React running!
The additional factor is how much REACT code has been fed into coding LLMs and be used to generate more 'applications'. I shudder to think of what might get producted.
I applaud the author's use of HTMX. I have seen it used with Java and Go backends very successfully and think for 99% of CRUD applications (tables and forms) it is more than sufficient. There will be applications that need to support more user interactivity for which HTMX (Alpine-AJAX, etc.) are insufficient. In that can there might be justification for a JS framework but personally I would need convincing.
That AI feedback loop is a scary thought—automating complexity rather than solving it.
I’m glad you mentioned Java and Go; it shows the hypermedia approach works everywhere. For 99% of CRUD, the "JS tax" just isn't worth it. I'd also need a lot of convincing to reach for a heavy framework now.
I have an example of an HTMX-based CRUD application that uses Node/Express backed by a SQLite database.
That’s a classic, rock-solid stack. I’d love to see how you’re handling the partial updates—are you using a specific templating engine like EJS or Pug to ship those HTML fragments?
I initially used JS template literals but this makes the backend vulnerable to code injection. I called on handlebars (hbs) through the express-handlebars package for a more robust solution.
The dependency hell is real. Moving back to more stable frameworks or even lighter setups feels like a breath of fresh air for long-term maintenance.
The point about South Asian network conditions is a huge wake-up call. We often develop on fiber and M2 chips, forgetting that a 2MB bundle is a massive barrier for someone on a spotty 3G connection in a Tier-2 city. HTMX isn't just a trend; it’s an accessibility win.
Exactly. Building for the real world means optimizing for low bandwidth. HTMX levels the playing field for users on spotty connections.
fair on the boilerplate pain but most of that's the ecosystem choices, not react. next.js defaults would've had that dashboard up in 15min. htmx wins when your server's already rendering - internal tools usually are.
Fair point on Next.js setup speed. But for CRUD and internal tools, I’d rather avoid the hydration and state sync dance entirely. HTMX just fits.
yeah the hydration dance for read-heavy tools just doesn't make sense. i shipped an internal dashboard with HTMX last quarter and the team says it's the easiest thing to modify in the whole repo.
The boilerplate fatigue is real. I’ve spent way too many hours setting up Vite, ESLint, and state management for projects that just needed a simple table. HTMX feels like a return to sanity where you actually focus on the logic rather than the plumbing. It is refreshing to see someone call out the "Vite config" nightmare.
You nailed it. The "plumbing" has become a full-time job lately. It is liberating to just write logic again without fighting a bundler for forty minutes first.
Sanity is the right word. Spending hours on Vite configs for a simple CRUD app is exhausting. It is great to get back to pure logic.
There is something deeply satisfying about the "HTML is the state" philosophy. It removes that awkward synchronization dance between the frontend and backend. If the server says the status is "Active," the HTML says it too. Simple.
It really simplifies the mental model. Getting rid of that middle layer for state management makes the whole stack feel way more cohesive.
Performance is where this stack really wins. Achieving a 100/100 Lighthouse score with a heavy SPA is a nightmare of optimization. With server-rendered fragments, the site is snappy by default. That is a massive win for technical SEO and user experience without needing a PhD in bundle splitting.
Exactly. Starting with high performance by default is much easier than trying to optimize a bloated SPA after the fact. HTMX makes that "snappiness" feel effortless.
Every so often I end up looking at HTMX and always come away from it concluding that it's 90% perfect, but not quite.
I like many aspects of it, but always just seems a bit too inflexible for the things I tend to need.
Still, I really agree with the point that a simple library is often enough. It doesn't always have to be a full framework; sometimes a micro-framework or even a simple helper library is enough.
I'm not quite at the point of warming up to jquery again but some days I feel like I'm slowly getting to that point 🤭
HTMX is definitely about finding the right tool for the job. It handles 90% of web needs, but for that last 10% of heavy UI, frameworks still rule.
Your opinion is absolutely valid. To be fair to HTMX, it is only a library so is not a 'one size fits all' solution. I found it quite adequate for CRUD applications. Sometimes a sprinkling of Alpine and few native web components can improved usability, but for anything requiring more user interactivity a JS framework might be the best answer. Of course there are other factors to consider such as the maturity and skills of the team as a whole but it is not a bad starting point.
Combining HTMX with Alpine or Web Components is a great middle ground. It keeps things modular without the full weight of a heavy SPA.
I felt that "twelve files open before a single line of logic" comment in my soul. The cognitive load of modern React (Zustand, Query, Router, etc.) is becoming a tax that many small projects simply shouldn't have to pay.
The overhead is real. For many projects, that "tax" yields zero ROI. HTMX lets you focus on the product instead of the plumbing.
In the freelance world, speed is everything. Clients on platforms like Fiverr or Upwork don't care about your component architecture; they want a working dashboard or e-commerce site by Friday. Django and HTMX let you ship a professional, production-ready MVP in record time. Simplicity is a competitive advantage here.
Efficiency is the best business strategy. When you can ship a working MVP while others are still configuring their folder structure, you win the client every time.
I love React and taught it for several years. I had a student at the time who was very excited about HTMX, and I did not get the hype then, but I definitely get it now, especially with how great it is for SEO/AEO. I appreciate you bringing a global perspective to the framework discussion as well.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.