Last year I spent forty minutes setting up a React project for an internal admin dashboard. Just the boilerplate. Vite config, ESLint setup, Tailwi...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
That is awesome to hear, especially coming from someone who taught React! It’s funny how HTMX can seem like a step backward until you actually see it solve modern problems like SEO so elegantly. Thanks for reading, and I really appreciate you noticing the global perspective—it's easy to forget that what works in a Silicon Valley bubble doesn't always apply everywhere else.
Svelte. Try teaching that and you'll see what you were missing while being besotted with React.
React setup in 2026:
install dependencies
install dependencies for dependencies
configure tool to configure another tool
watch npm download the GDP of a small nation
HTMX:
“put hx-get here bro”
This made me laugh because it’s painfully accurate 😭
Modern frontend tooling sometimes feels like maintaining an ecosystem just to render a form and a table. HTMX feels refreshing because it brings the focus back to shipping functionality instead of endlessly managing abstraction layers.
Honestly this is why backend devs stay suspicious of frontend tooling 😄
React: “we just need a simple form”
Also React: adds 14 packages, 3 configs, and a philosophical debate about state management
HTMX: “server sends HTML, browser shows HTML”
Frontend complexity immediately evaporates like a Spring Boot startup log after you ignore it for 2 seconds
Install dependencies for dependencies
you took me out with that one 😆
Haha, glad you caught that!
One can not compare HTMX with Web Components
HTMX is a DOM-enhancement library, Web Components create DOM
hx-attributes and transform DOM into some other DOM, or do something HTMX-else<tag-name>encoutered will become a Custom Element, creation not transformationThat also means with Web Components you can set
el.innerHTML = "<my-button></my-button>";anytime you want, and the DOM element will automagically upgrade,
and do its Custom Element thing.
Because Web Components are baked into the Browser.
With HTMX you can set
el.innerhtml = "<button hx-post="/clicked" hx-swap="outerHTML">Click Me</button>"... and nothing will happen
the HTMX developer has to execute:
htmx.process(el)after HTML was parsed to DOMHTMX is a DOM-enhancement library, Web Components create DOM
* Yes, (since 2016) any
<tag-name>(without using JavaScript) becomes a valid Custom Element/HTMLElement, great for layout an styling, no more DIV-soup. JavaScript adds more functionality to the Web Component (and everybody mixes the terms Custom Element/Web Component)<tag-name>is a UNdefined Custom Element (but valid HTMLElement!)customElements.define("tag-name")makes it a defined Custom ElementWhile you make a fair point about how they handle DOM lifecycle and initialization under the hood, comparing HTMX and Web Components is still common because developers often choose between them to solve the same high-level problem: building dynamic user interfaces without a heavy SPA framework. They aren't mutually exclusive, but they represent different architectural philosophies for the modern web.
Also, your comment reads like it was generated by an AI.
Also, your comment reads like it was generated by an AI.
Thank you, I will consider that a compliment. The text is an extract from the Web Components site I am building. And yes, I do use AI to correct my English, I am not a native speaker/writer.
Then make it a fair comparison.
HTMX is declarative (percieved as easier) and a lot of sugar.. its a 56KB gzipped download for a reason.
One of the HTMX sugar cubes is
hx-get="file.html"Web Components that do more than just presentation need JavaScript,
a HTML (or any file) import
<load-file src="file.html">is 7 lines of code:Of course you can get cheeky and rename
load-filetohx-getI fully agree,
Just as web components are objects too and then using 'innerHTML' ?
Better use 'append / appendChild' and inject the DOM directly!
The OOP way!
Yeah, that’s a good point — direct DOM manipulation with append/appendChild is way cleaner and safer than innerHTML in most cases.
appendChildis oldskool Internet Explorer syntax, and used by almost every AI answer, because AI is 'trained' on old content.appenddid not exist in IE, and is way more powerfulHTML — Hyper Tangled Messy Lines
Power to the DOM!
appendChild(returns the created Element) never required becausecreateElementreturns the DOM element.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.
nice
thankyou
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.
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.
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.
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.
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.
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.
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.
This is exactly how I feel after building Horilla HRMS and CRM with Django + HTMX.
For most business apps, I really don’t think we need the complexity of a separate React frontend and Django backend. HRMS and CRM systems are mostly forms, tables, filters, approvals, dashboards, and partial page updates — and HTMX handles these beautifully.
What I love most about HTMX is how simple it is to start using:
just add the HTMX script in your Django index.html and suddenly attributes like hx-get, hx-post, hx-target, hx-trigger, and hx-select make pages interactive without building an entire frontend architecture.
No API duplication.
No frontend/backend sync issues.
No massive node_modules.
No spending days configuring tooling before building actual features.
While working on Horilla, I felt this approach helped me move extremely fast while building modules like attendance management, recruitment pipelines, employee workflows, approvals, CRM flows, and dashboards — all while keeping the stack simple and maintainable.
Horilla is a perfect example of this. Building an HRMS or CRM with a split React/Django stack usually means wrestling with state sync and double-defining schemas just to render tables and forms.
HTMX cuts through that bloat. Keeping the business logic entirely in Django while using hx-target and hx-trigger for seamless partial updates is a massive productivity win. It proves you don't need a heavy SPA architecture for fast, interactive enterprise apps.
Exactly 💯
This is a useful debate because the real issue is not React versus HTMX, it is architecture fit. React is still valuable when the product needs rich client state, offline behavior, complex workflows, or highly interactive UI. But for simpler CRUD or server-driven dashboards, teams should absolutely question whether they are paying unnecessary complexity tax. The best frontend decision is usually the one that matches interaction complexity, team skill, and long-term maintainability.
The "complexity tax" is the perfect way to put it. We've spent years defaults-choosing massive SPA architectures for apps that are essentially just forms and tables. Matching the tool to the actual interaction complexity of the product saves so much time and engineering headache. Thanks for bringing this balance to the discussion!
A balanced and thoughtful piece. One consideration worth adding: the HTML-fragment model does introduce trade-offs that deserve attention. On the security side, returning rendered markup places greater responsibility on server-side escaping and CSRF protection, which is manageable in Django or .NET but less forgiving than the JSON boundary. On the architectural side, server-rendered fragments reduce client-side dynamism and tie the response format to a single consumer, which can become a limitation when latency is high or when the same data must serve multiple client surfaces.
These are excellent points, Hussein. The security aspect is often overlooked—relying heavily on server-side escaping means a single mistake can be costly. And you are totally right about the coupling effect; if you ever need to pivot to a native mobile app later, that HTML-fragment backend suddenly becomes a bottleneck. Thanks for adding this balanced critique!
The whole REACT system is shit! I've felt it after working on it for years. OVERengineered shit
Complexity often creates more problems than it solves. What's your preferred stack for keeping things lean and maintainable without the overengineering?
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. -- this hits me
Combining the version control of Git with the safety of Rust and the speed of Go into a narrative sounds like a fun challenge. I will definitely work on a story-driven post for these three soon.
You need to try native web components, either in vanilla code or using Lit. It is a powerful tool in conjunction with HTMX.
I appreciate the honest feedback. Some topics are definitely more "dry" than others, but they are often the most vital for long-term growth. I will try to spice up the delivery in the next one to keep it engaging.
"use server" and "use client" in React 🤮
Haha, you’re definitely not alone there. The community is completely split on it. ( i misunderstood it before )
The connectivity perspective is spot on. We often forget that users on mobile data in cities like Karachi or Hyderabad struggle with heavy JS bundles. Keeping things lightweight isn't just a preference; it's a necessity for accessibility. If your app takes 10 seconds to hydrate on a 3G connection, you've already lost the user.
This is the most important point. Accessibility isn't just about UI; it's about network reality. Respecting the user's data and device is a hallmark of good engineering.
HTMX is great for server interactions. For client interactions, and for server actions, React is just okay. To be honest, React is no longer just a library; it's a framework that practically requires Next.js, TanStack, and other tools to be productive. Compared to other frameworks, React still has a lot of room for improvement; things like signals, hypermedia over streaming chunks of JavaScript, and a more. But despite its shortcomings, React remains the most widely used option. It has a large, active community, it's now under the Linux Foundation, and AI tools understand it very well.
React definitely feels more like an entire ecosystem or meta-framework requirement now just to get basic things running. The community backing and AI tooling support are massive advantages that keep it on top, but the architectural bloat is exactly why people are looking for alternatives. Appreciate you adding this context!
You can still build high-end, luxury interfaces with this stack. A dark theme with smooth CSS transitions and animated gradients works just as well with HTMX as it does with React. You don't need a heavy framework to make something look premium; you just need solid CSS and a fast response time.
Browsers have become incredibly powerful at handling animations and styles natively. You don't need a massive JS footprint to create a "premium" feel.
The South Asian context you mentioned is heavily slept on in mainstream tech discourse. When you’re dealing with inconsistent 3G/4G connections in Tier-2/3 cities or building a custom ERP for a local merchant on a razor-thin budget, telling them they need to wait for a massive JavaScript bundle to hydrate is a tough sell.
This is the reality check a lot of mainstream discourse avoids.
You don’t need a full React SPA just to manage forms, tables, and admin panels for local businesses. In those cases, server-rendered simplicity isn’t “old tech” — it’s efficient engineering.
The more constraints you actually have, the less “modern stack” matters.
This perfectly captures the growing fatigue a lot of developers feel but rarely articulate well. React isn’t “bad” — it’s just become the default answer for problems that don’t actually require SPA-level complexity.
The South Asian context you mentioned is especially important. A fast, maintainable Django + HTMX app that ships in days is often far more valuable than a “modern” stack with 12 dependencies and a month of setup overhead. Most businesses just need reliable CRUD, not a browser-based operating system.
Also loved this line: “The HTML is the state. The server renders the HTML. You’re done.” That philosophy feels refreshing again in 2026.
Yeah, that’s the part people miss — “modern” doesn’t automatically mean “better for the problem.”
Most real-world apps are still CRUD + auth + dashboards, and Django + HTMX nails that with way less moving parts and far fewer failure points.
And exactly that line — server-rendered simplicity feels almost underrated again because we overcomplicated the frontend for problems it didn’t need to solve.
This is one of the few frontend discussions that actually focuses on engineering tradeoffs instead of framework tribalism. The point about spending more time configuring tooling than building actual business logic is painfully relatable for CRUD apps, admin panels, and internal dashboards.
I especially appreciated the South Asian perspective. A lot of frontend conversations assume fast internet, high-end devices, and unlimited engineering budgets, but that’s not the reality for many users or teams. In those environments, lightweight server-rendered apps aren’t “old school” — they’re practical engineering.
The “HTML is the state” idea is also refreshing. For many business applications, removing unnecessary synchronization layers between frontend and backend dramatically simplifies development and maintenance.
React still absolutely makes sense for highly interactive products like collaborative editors, realtime apps, or complex client-side workflows. But for forms, tables, filters, and dashboards, HTMX + Python feels like a much more intentional fit than defaulting to SPA complexity because the ecosystem normalized it.
Really thoughtful write-up overall. It’s good to see more developers questioning whether architectural complexity is actually solving a real problem.
Yeah, you’ve framed it exactly the right way — it’s not about replacing React, it’s about not defaulting to it blindly.
Most teams don’t need SPA-level architecture for typical business systems. Forms, tables, filters, admin flows… they already fit the request–response model naturally, and HTMX just keeps that model intact instead of rebuilding it on the client.
And the South Asian angle matters more than people admit. “Lightweight” isn’t a preference in those cases, it’s a constraint. If the app feels slow on a mid-range Android with unstable data, all the fancy frontend architecture doesn’t matter.
React earns its place in high-interaction products, no doubt. But for everything else, simpler isn’t a downgrade — it’s just cleaner engineering.
The 'organizational tax' of building a full SPA for an internal dashboard or a basic CRUD app is a hidden cost teams are finally waking up to. When your backend is already written in something highly productive like FastAPI or Django, forcing a clean separation of concerns via a JSON API layer usually just means writing duplicate validation logic on both sides of the network boundary.
Your point about returning raw HTML fragments directly into the DOM via hx-target completely eliminates that serialization dance.
Mira. 👍 That "serialization dance" is exactly what burns so much development time. Writing the same validation logic in Python and then duplicating it in TypeScript or JavaScript just feels like running in place after a while.
The South Asian freelancer/SaaS context you highlighted is so often overlooked in mainstream tech discourse. When dealing with tight client budgets on Upwork/Fiverr and users on mobile data in Pakistan, bypassing the "SPA tax" isn't just about developer preference—it's a massive, material advantage for shipment speed and performance.
Exactly, Sualeh. Mainstream tech discourse heavily over-indexes on Western infrastructure where high-speed fiber and high-end hardware are the defaults. In regions like Pakistan, mobile data constraints and low-end devices make the "SPA tax" incredibly expensive. Prioritizing lean, server-rendered, or hybrid architectures isn't retro—it's a massive competitive advantage for conversion and deployment speed on platforms like Upwork and Fiverr.
What makes this article valuable is that it separates “modern” from “necessary.” React is incredible for highly interactive products, but most teams are not building Figma-level interfaces — they’re building dashboards, CRUD systems, and internal tools. The Python + HTMX approach feels refreshing because it optimizes for delivery speed, simplicity, and maintainability instead of endless frontend complexity. The South Asian developer perspective was especially important too. In markets where bandwidth, budgets, and small teams matter, reducing architectural overhead is a real engineering advantage, not a shortcut.
Really appreciate this. That “modern vs necessary” distinction is exactly the core argument. A lot of developers inherit architectural complexity by default without questioning whether the product actually benefits from it. For many teams — especially in South Asian markets — simplicity, faster delivery, lower hosting costs, and easier maintenance are genuine competitive advantages, not compromises.
This article nails something the industry is finally starting to admit: most apps are not Figma. For CRUD dashboards, admin panels, booking systems, and internal tools, the React ecosystem often introduces more architectural overhead than actual business value.
The strongest point here wasn’t “React bad,” it was “architecture should match the problem.” That’s the conversation more teams need to have.
The South Asian perspective was especially important too. A lot of frontend discussions assume fast internet, high-end devices, and huge engineering budgets. In reality, lightweight server-rendered apps can dramatically improve usability on unstable mobile networks and lower-end hardware.
React absolutely still dominates rich client-side applications, realtime collaboration, and highly interactive UI. But for forms, tables, filters, and workflows, HTMX + Python feels like a return to pragmatic engineering instead of default complexity.
“HTML is the state” is honestly one of the most refreshing ideas making a comeback right now.
Really appreciate this perspective. The South Asian reality matters a lot more than global frontend discourse admits. For many teams, reducing infrastructure, deployment friction, and frontend complexity directly impacts shipping speed and business survival. React absolutely has its place — but not every dashboard needs a mini distributed system to render a table.
The strongest part of the write-up is the focus on architecture fit instead of framework tribalism. React is incredible for highly interactive products where the UI itself is the product — collaborative editors, realtime apps, complex client-side workflows.
Exactly. React is amazing when the interface itself is the product, but a lot of teams default to SPA complexity for apps that are mostly forms, tables, and workflows. The goal shouldn’t be “use the trendiest stack,” it should be “solve the problem with the right architectural weight.”
Finally someone said it.
A lot of developers are rebuilding simple CRUD apps with 400MB frontend stacks when HTMX + Python can do the job faster, simpler, and with less mental overhead.
React is still powerful for highly interactive apps, but for many products today, complexity became the default instead of the requirement. Solid article.
Somewhere along the way, we normalized installing thousands of npm packages just to render a simple form. There is an incredible amount of freedom in going back to a server-driven architecture where you don't have to duplicate your state on both the client and the backend. React definitely has its place, but "complexity by default" is the perfect way to put it. Thanks for the support!
This was one of the few React vs HTMX discussions that actually felt grounded in real engineering tradeoffs instead of framework tribalism.
The strongest point wasn’t “React bad” — it was the reminder that architecture should match the problem. Most business software is still forms, tables, filters, dashboards, and workflows. For that category of apps, shipping HTML fragments from the server is often simpler, faster, and easier to maintain than managing hydration, client state, API contracts, and frontend infrastructure.
The South Asian perspective was especially important. A lot of frontend conversations assume fast internet, modern devices, and large engineering budgets. In reality, many users are still on unstable mobile data and lower-end hardware. Lightweight server-rendered apps aren’t “old school” there — they’re practical engineering.
React absolutely still makes sense for highly interactive products like collaborative editors, realtime interfaces, and complex client-side apps. But for CRUD-heavy systems, HTMX + Python feels like a strong reminder that the web platform itself was already extremely capable.
“HTML is the state” is honestly one of the most refreshing ideas making a comeback right now.
Yeah, this is the part people keep missing — it’s not “React is bad”, it’s “React is often unnecessary for the problem being solved.”
The South Asian context you brought up is an incredibly vital point that most tech discourse completely ignores. Highlighting the network reality in cities like Karachi or Hyderabad transforms HTMX from a trendy developer preference into a literal accessibility necessity. When hydration delays on low-end devices mean losing a user entirely, minimizing the JavaScript footprint becomes a core business requirement.
The simplicity of the mental model is unmatched. Bypassing the API synchronization dance, CORS headaches, and folder-structure fatigue means developers can just focus on shipping core business logic instead of maintaining complex plumbing.
For the vast majority of standard CRUD dashboards, internal tools, and freelance MVPs, this approach isn't just a nostalgic step back—it’s an economical, production-ready competitive advantage.
I really appreciate you highlighting that. Living and developing here in Hyderabad, you quickly realize that the 'modern web' isn't one-size-fits-all. When your users are on spotty 3G/4G connections or budget smartphones, a massive JavaScript bundle isn't just a performance bottleneck—it's a complete barrier to entry. HTMX genuinely shifts the conversation from developer aesthetics to actual digital inclusion.
This perfectly explains why HTMX + Python is gaining momentum in modern web development. Most business apps are CRUD-heavy dashboards, not real-time design tools, and React often adds unnecessary complexity for those use cases. The point about South Asian developers shipping faster with Django + HTMX on tight budgets is especially accurate. Simpler architecture, faster deployment, better performance — that combination matters more than hype in 2026.
Exactly, Yahya! You summed up the reality of it perfectly. In 2026, the hype cycle is finally starting to give way to practical engineering economics. When 90% of what a client or business needs is a reliable, fast CRUD dashboard, building a massive SPA with a decoupled API layer is often just over-engineering for the sake of it.
The Django + HTMX stack is an absolute powerhouse for this. You get all of Django's built-in robustness (auth, ORM, admin panel) combined with HTMX's ability to give you smooth, reactive UX without leaving the backend ecosystem. For developers on tight budgets and strict timelines, skipping that entire layer of frontend state management and build-tool configuration isn't just a time-saver—it's the difference between shipping a profitable product or getting stuck in development hell. Appreciate you tuning into that architectural shift!
This is one of the few React vs HTMX discussions that actually focuses on engineering tradeoffs instead of turning into another frontend religion war.
The strongest part of the article is the reminder that most applications are not Figma-level interactive products. Most teams are building CRUD systems, dashboards, booking platforms, inventory tools, and internal admin panels where simplicity, maintainability, and shipping speed matter more than having the “modern” stack.
The South Asian developer context you mentioned is especially important and rarely discussed. In markets where budgets are tight, internet speeds vary, and small teams need to move fast, Django/FastAPI + HTMX is not “old-school” — it’s practical engineering. Eliminating unnecessary API layers, hydration costs, and frontend complexity can be a massive productivity advantage for freelancers and early-stage startups.
I also appreciated the balanced take on React. React absolutely shines for highly interactive, client-heavy applications, but too many teams default to SPA architecture before asking whether the problem actually requires it.
“No node_modules folder the size of a small country” made me laugh because every developer who has fought dependency hell felt that line instantly 😄
Great write-up. This feels less like “React is overkill” and more like “choose complexity intentionally.” That’s a conversation the industry needs more of.
Yeah, this is exactly the point most “React vs X” debates miss — it’s not about ideology, it’s about constraints.
In real South Asian freelance/startup work, speed, simplicity, and reliability matter more than architectural purity. If a Django + HTMX setup ships faster and breaks less, that’s just better engineering for that context.
React still has its place, but defaulting to it everywhere is where people start overengineering basic CRUD problems.
This is an incredibly grounded take, Syed. You hit the nail on the head regarding the South Asian tech landscape. In markets like Pakistan, where connectivity variance is real and clients/freelance gigs lean heavily toward rapid CRUD/admin tools, the "SPA tax" is often completely unjustified.
Agree with this completely. The industry forgets that not every user is on fiber internet and not every project is a Silicon Valley product.
When latency, budget, and team size are real constraints, fewer moving parts usually wins. SPA-first thinking often adds cost without adding real value.
Context > trends, always.
This is one of the most grounded discussions about React and HTMX I’ve read because it focuses on architecture fit instead of framework tribalism. The point about spending more time configuring tooling than building actual business logic is painfully accurate for CRUD apps, dashboards, and internal tools. “HTML is the state” is such a powerful idea because it removes unnecessary synchronization layers and keeps the mental model simple.
Yeah, this is the real shift people are slowly waking up to.
Most “frontend complexity” isn’t solving product problems — it’s solving tooling problems that the ecosystem created for itself. For CRUD apps, dashboards, admin panels… you end up wiring more state, build steps, and client-side logic than actual business logic.
And “HTML is the state” is powerful because it removes that extra synchronization layer entirely. Server becomes the source of truth again, and suddenly half the mental overhead disappears.
React still has its place, but defaulting to it for everything is where teams waste time. Architecture should follow the problem, not trends.
The article makes a strong case for a trend that’s very real: a lot of teams are reconsidering whether a full SPA stack is justified for ordinary business applications. But the title (“React is Overkill”) is intentionally provocative. The deeper argument is really about architecture fit, not React becoming obsolete.
React still owns the high-interaction space — no argument there. But defaulting to SPAs for everything is what this article is pushing back against, and that pushback is long overdue
This is one of the most thoughtful discussions around React, HTMX, and modern web architecture I’ve read because it avoids the usual “framework tribalism” and focuses on the thing that actually matters: matching technical complexity to business reality.
The strongest part of the article is the distinction between applications that genuinely require SPA-level interactivity and applications that simply inherited SPA complexity because the industry normalized it. That difference is huge. Most dashboards, CRMs, booking systems, HR tools, admin panels, and internal platforms are fundamentally request-response systems built around forms, tables, filters, and database operations. Yet many teams automatically default to React ecosystems that introduce hydration layers, state synchronization problems, API duplication, routing complexity, caching strategies, and massive dependency chains before solving a single business problem.
The “twelve files open before writing application logic” line captures modern frontend fatigue perfectly. A lot of developers now spend more engineering energy maintaining tooling than building products. Vite configs, ESLint rules, hydration mismatches, state libraries, server/client boundaries, bundlers, query layers, and deployment pipelines have become an entire secondary profession around frontend development.
What makes the HTMX argument compelling is not nostalgia or anti-JavaScript sentiment — it is architectural efficiency. “HTML is the state” dramatically simplifies the mental model for CRUD-heavy systems because the server remains the single source of truth. There is no duplicated business logic between frontend and backend layers. No separate API contract to maintain for simple interactions. No constant synchronization between local state and server state. For many business applications, that reduction in cognitive overhead directly translates into faster development, easier onboarding, and lower long-term maintenance costs.
The South Asian perspective in this article is especially valuable because most framework discussions completely ignore real-world infrastructure constraints. In regions where users rely on unstable mobile networks, older Android devices, and limited bandwidth, lightweight server-rendered applications are not “old-fashioned” — they are practical performance engineering. A 2MB JavaScript bundle is not an abstract optimization issue there; it directly affects usability and accessibility. That context rarely gets discussed in Silicon Valley-centric frontend conversations.
I also appreciated that the article stayed balanced about React. That makes the argument significantly stronger. React absolutely earns its complexity for products where the UI itself is the product: collaborative editors, realtime design tools, offline-capable systems, advanced data visualization platforms, and highly interactive client-side workflows. In those environments, component-driven architecture and rich client-side state management are genuinely powerful.
But the article correctly points out that most products are not Figma or Notion.
Another underrated insight here is developer onboarding and organizational structure. A backend-heavy team with strong Python skills can become productive with Django + HTMX almost immediately because the architecture aligns with existing mental models around HTTP, templates, routing, and server-side rendering. Meanwhile, modern React ecosystems often require developers to internalize entirely new paradigms around hydration, hooks, effects, routing boundaries, client/server rendering distinctions, state orchestration, and frontend infrastructure before shipping meaningful features.
That cognitive load is real, especially for students, freelancers, startups, and small engineering teams where speed and maintainability matter more than architectural fashion.
The article also highlights something the industry is slowly rediscovering in 2026: the web platform itself was already incredibly capable. For years, frontend ecosystems abstracted away HTML and HTTP in pursuit of richer interactivity, but many teams are now realizing that simpler architectures often deliver better performance, better SEO, lower maintenance overhead, and faster iteration cycles for the majority of business software.
This was not a “React bad” article. It was a strong argument for intentional engineering decisions instead of defaulting to complexity because the ecosystem normalized it. That distinction makes this discussion genuinely valuable.
Most business apps are still just structured CRUD flows with predictable state. In that space, HTMX + server rendering reduces moving parts without sacrificing capability. Less state duplication, less API glue, fewer failure points.
So true. We spent a decade convincing ourselves that every basic CRUD app needed to be a distributed system with a massive JS bundle, just to end up recreating server-side rendering with RSCs anyway.
Python + HTMX just lets you build without the configuration hangover or the node_modules black hole. It’s wild how much faster you can ship when you aren't managing two separate deployment pipelines for a simple form and a table. Nice write-up.
The "configuration hangover" is real. It’s hilarious and a bit ironic that the JS ecosystem spent years moving everything to the client, only to spend the last few years engineering complex ways (like RSCs) to bring it back to the server. Eliminating that dual-pipeline headache is a massive win for HTMX.
I have also mostly worked on Python + HTML + SCSS or Tailwind CSS, and it gets the job done. However, for a recent project, I decided to build a React dashboard, and that dashboard, along with React and its dependencies, took up a sizeable chunk of my time. Though I won't lie, I liked the UI better than the Streamlit dashboard. I think it all boils down to the specific application and customer-base requirements, as you mentioned in the startup example, because React does require rigour.
That’s a really great, nuanced take, Iman. You’re spot on—React definitely requires rigor, and the setup overhead for a dashboard can be exhausting compared to a quick Python/Streamlit build. But you're right, when it comes to slick, complex UI interactions and customer expectations, that extra effort sometimes pays off. It's all about balancing that trade-off!
This was refreshing to read because it focuses on developer productivity instead of frontend tribalism. The Python + HTMX approach makes a lot of sense for teams that care more about shipping fast, reducing complexity, and maintaining simpler stacks. React is still powerful, but for many CRUD-heavy apps, the overhead is becoming harder to justify. Great perspective on where web development is heading
Thanks, Yash! "Developer productivity over frontend tribalism" is exactly what I was aiming for. React is incredible for highly interactive, state-heavy apps, but forcing it onto every standard CRUD app just creates unnecessary roadblocks for teams that just need to ship. Glad the perspective resonated with you!
This nails a shift a lot of developers are quietly realizing: most apps don’t need a full SPA architecture. HTMX feels less like “going backwards” and more like removing unnecessary layers between the developer and the product.
"Removing unnecessary layers" is the perfect way to describe it.
As someones who often defaults to React for all projects, this piece has motivated me to explore other setups. I will give Python + HTMX a try for some of my internal tooling!
Python and HTMX is a good combo for internal tools in my eyes. You will probably find it much faster to ship since you are staying in one ecosystem.
This is one of the few React vs HTMX discussions that actually focuses on engineering tradeoffs instead of framework tribalism. The part about spending more time configuring Vite, routing, state management, and hydration than building the actual dashboard is painfully relatable for anyone who has worked on internal tools or CRUD-heavy SaaS products.
Your point about the South Asian developer ecosystem is especially important and rarely discussed. In regions where users are still dealing with unstable mobile data and lower-end devices, lightweight server-rendered apps are not “old school” — they are practical performance engineering. A Django + HTMX stack delivering fast HTML fragments often creates a better real-world UX than shipping megabytes of JavaScript for simple forms and tables.
I also appreciate that you didn’t frame React as “bad.” For products like Figma, Notion, collaborative editors, or realtime analytics platforms, React absolutely earns its complexity. But for admin panels, HR systems, booking platforms, and MVPs, the simplicity of Python + HTMX can dramatically improve developer velocity, SEO, maintainability, and deployment speed.
“HTML is the state” might be the most underrated philosophy in modern web development right now.
Thank you, Sana. I am really glad the South Asian context resonated with you. When your users are on spotty mobile data and budget devices, cutting out megabytes of JavaScript bundle overhead is a massive, tangible win for accessibility, not just a theoretical Lighthouse score.
Acknowledging React's strengths is crucial because it keeps the conversation grounded in engineering realities rather than just hype. For highly collaborative, client-side heavy platforms like Figma, React is phenomenal. But for standard business software, focusing on "HTML is the state" lets teams cut through the noise, bypass the hydration headaches, and focus purely on developer velocity and real-world performance.
This is a solid walkthrough! Clean code and good explanations. For anyone building in public: the feedback loop from your audience is invaluable - use it wisely. If you're struggling with growth outreach, tools like Rixly can help find developers already interested in your niche.
Building in public has been a part of my journey so far, and I definitely value that feedback loop. Thanks for the kind words and for sharing that resource.
This article nails a conversation the web development industry has been avoiding for years: most products do not need SPA-level complexity. The point about spending more time configuring React tooling than building actual business logic is painfully accurate, especially for CRUD dashboards, admin panels, HR systems, and internal tools where users care about speed and reliability more than frontend architecture purity.
What really stood out to me was the South Asian developer perspective. That context is almost never discussed in frontend debates. In regions like Pakistan, India, and Bangladesh, performance is not just a Lighthouse score flex — it directly impacts usability for people on low-bandwidth mobile connections and older devices. A lightweight HTMX + Django/FastAPI stack is not “old school”; it is practical engineering optimized for real-world constraints.
The biggest strength of Python + HTMX is reducing unnecessary architectural duplication:
For startups validating ideas, freelancers shipping client work, or small teams maintaining business software, that simplicity translates directly into faster delivery and lower maintenance costs.
I also appreciated that this wasn’t framed as “React bad.” The article correctly acknowledges where React still dominates: highly interactive applications like Figma, Notion, collaborative editors, realtime dashboards, and complex client-side workflows. That balance makes the argument much stronger and more credible.
Another underrated point is developer onboarding. A junior Python developer can understand server-rendered templates with HTMX in days, while modern React ecosystems often require understanding routing, hydration, hooks, state management, caching layers, bundlers, and deployment pipelines before shipping meaningful features. That cognitive overhead is real.
The “HTML is the state” philosophy is honestly refreshing in 2026. We spent years abstracting away the web platform, and now many teams are rediscovering that HTML + HTTP were already extremely powerful primitives when used correctly.
Excellent write-up. This is one of the few framework discussions that actually focuses on engineering tradeoffs, maintainability, developer velocity, SEO performance, and product reality instead of hype cycles.
Thank you for this brilliant addition to the discussion, Hashir. You hit the nail on the head regarding the South Asian context—building for low-bandwidth mobile connections and older hardware completely changes the definition of "modern" web development.
The reduced cognitive overhead and elimination of massive dependency chains are huge wins for developer velocity. It is great to see more engineers rediscovering that HTML and HTTP are incredibly powerful primitives when we stop over-engineering simple CRUD apps. I appreciate you highlighting these exact trade-offs.
What I was going to say?
Ah, yes:
🤮
Zero articles, zero value, just emojis. Bold of you to stick your tongue out like you’re doing something, when the only thing you've 'shipped' is a comment nobody asked for. Stick to your yo-yo; logic clearly isn't your game.
Daneil be like: I will write nothing but make my mother fucked with every boy i found to be my dad
Do not agree, react will survive like java script, python has its own challenges when it comes to sleek smooth frontend and backned
React’s survival isn't the issue; it’s about using the right tool. For 99% of CRUD apps, React is just unnecessary weight.
fair point — right tool for the job. i use react for
anonpolls because real-time vote updates and complex
state made sense. for a simple CRUD form? probably
overkill yeah.
thankgod someone finally understood the point
What makes this article strong is that it doesn’t argue “React bad, HTMX good” in the usual reactionary way. It frames the real issue correctly: architectural weight should match problem complexity. That distinction gets lost constantly in frontend discourse.
The part about South Asian developer realities was especially important. A lot of modern frontend advice assumes high-end hardware, stable internet, large teams, and clients willing to absorb engineering overhead. But for freelancers, student teams, and small SaaS builders in places like Karachi, Lahore, or Hyderabad, reducing deployment complexity and shipping faster is not some philosophical preference — it’s economic leverage.
The strongest point in the article is probably this: most apps are not Figma. Most apps are CRUD systems with filters, forms, authentication, and dashboards. In those cases, adding separate frontend/backend repos, API contracts, hydration layers, client-side caching, and endless dependency maintenance often creates more organizational complexity than user value.
I also appreciated that you acknowledged where React still dominates. Collaborative tools, realtime interfaces, and highly interactive client-state-heavy apps genuinely benefit from the SPA model. That balance made the HTMX argument much more credible.
The “no node_modules folder the size of
That “modern vs necessary” distinction is exactly the conversation I wanted to push. Simplicity is underrated in software engineering right now. A smaller stack with fewer moving parts often means faster iteration, easier onboarding, lower hosting costs, and fewer production headaches — especially for small teams and freelancers.
I have been using htmx for almost everything this year. Really liking it.
That’s awesome to hear, Travis!
except reactjs, you could suggest astro js + htmx . I think it will be better solution this way.
That is an absolute powerhouse of a combination, Nikhil! Astro + HTMX is a match made in heaven.
I completely agree with your point about consistency. It is the one thing people overlook when trying to reach a goal.
People often underestimate the boring work. Showing up every day and keeping things uniform matters way more than a random burst of intensity.
You always find a way to explain complex topics so clearly. I really appreciate the depth you put into your posts.
I appreciate the feedback. I'd rather give the full technical picture than a shallow summary. Glad the depth was useful
This is such an insightful perspective. I had never looked at the situation from that specific angle before.
Sometimes we just need to take a step back and look at the fundamentals to see the bigger picture. I am happy it gave you a new outlook.
NextJs solves some of this issues.
True, but Next.js often feels like adding another layer of complexity just to fix problems that HTMX avoids entirely.
React simplifies UI state, but often redistributes complexity into the stack rather than removing it. :)
exactly and the whole writing of it was this
Can you please write on Git, Rust and Go in a story telling way ?
There is a great narrative to be found in the tension between Git’s "time travel" capabilities, Rust’s strict safety rules, and Go’s focus on high-speed efficiency. I will start drafting a post that weaves these three into a story for you soon. Stay tuned!
I hope it gets into top 7 of week, it was good but Abit boring topic
I appreciate the honest feedback. Sometimes the "boring" fundamental topics are the most necessary for growth, but I’ll definitely aim to make the next one more engaging while keeping the depth. Glad you still found it good overall.
HTMX has been such a breath of fresh air lately. I've been using it for a few side projects and it really simplifies things compared to a full React setup. Interesting to see this trend growing!
It really is a breath of fresh air, Adarsh! Getting off the JavaScript build-tool treadmill for side projects is incredibly liberating. Glad you're enjoying the trend! 👍
React is still great for highly interactive apps, but HTMX + Python definitely looks more productive for many server-driven projects.
It’s definitely not a zero-sum game. If you're building something like Figma or a massive, highly collaborative dashboard, React is still king. But for the 80% of web apps that are essentially wrappers around a database, the Python + HTMX productivity boost is just too good to ignore.
React isn’t dead, but most websites don’t need a spaceship to cross the street. Python + HTMX is winning because simplicity scales faster than complexity.
"Don’t need a spaceship to cross the street" is the perfect way to put it, Michael.
so you mean react is like deprecated for small projects
Not deprecated, just often overkill. For small projects, React adds unnecessary complexity and bundle size. Tools like HTMX or vanilla JS let you build faster with less overhead.
How about AGI vs AI ?
AI is the broad field of machines doing smart tasks (like ChatGPT or image generation). AGI (Artificial General Intelligence) is the future goal: an AI that can learn, think, and solve any intellectual task just like a human can. I will think on this deeply now
How you created this featured image
I used Gemini ( Nano Banana ) and Canva
React is fantastic for heavy, highly interactive client-side apps, but for the other 85% of the web—the dashboards, forms, and admin panels—Python + HTMX feels like a cheat code. Great write-up!
We’ve spent years over-engineering standard CRUD apps, dashboards, and internal tools with massive client-side bundles and complex state management, when all we really needed was to send HTML over the wire. React absolutely has its place for highly dynamic, desktop-like web apps (think Figma or complex real-time editors), but for everything else, the Python + HTMX stack cuts out so much unnecessary boilerplate. It lets you build fast, secure, and performant apps without the JavaScript fatigue. It really does feel like a cheat code for productivity.
Both have different use cases also
Absolutely, they are entirely different beasts. While Python + HTMX is incredible for quickly shipping CRUD apps and keeping complexity low by keeping everything server-side, you still can't beat React (or similar frontend frameworks) when you need heavy, offline-first client state or highly interactive, desktop-like UI experiences. It’s all about picking the right tool for the job rather than riding the hype wave. 👍
I am hearing HTMX for the first time , what is it ? I am a new developer
HTMX is a tool that lets you build modern, interactive websites using just HTML, without writing tons of complex JavaScript.
Traditionally, to make a page update dynamically (like a "like" button), you’d need a JS framework like React. HTMX lets you do that directly in your HTML tags. It’s gaining massive traction in 2026 because it makes web development much simpler and faster for many projects.
The mobile data point is huge and rarely discussed. Bundle size isn't just a performance metric—it's a real-world accessibility issue for a massive chunk of users.
Exactly, Sastra! This is the part that often gets lost in high-speed office fiber-optic bubbles. A 2MB JavaScript bundle isn't just a slow spinner; it's actual money out of a user's pocket on limited data plans, or a completely broken experience on a spotty 3G connection. Shifting that weight back to the server is a massive win for true digital accessibility. Thanks for bringing this up!
htmx is so good honestly, react fatigue is real been looking into it more lately
React fatigue is incredibly real, and you are definitely not alone in feeling it. Over the last few years, the ecosystem has become so complex with competing meta-frameworks, hydration hurdles, and endless configuration that it often drains developer velocity.
Now i am thinking to explore python after reading this
you should
Been there—days fighting bundlers for a simple dashboard. HTMX is the breath after a React marathon: faster, simpler, and somehow still modern. If it works, why overengineer?
There’s a certain point where the overhead stops feeling like "best practice" and starts feeling like a barrier. It’s a relief to just write a few lines of HTML and have things work without a massive build step in the middle. Staying lean is definitely a superpower for dashboards.
I've not looked back since discovering HTMX, but I'm using server code written in Delphi.
That’s awesome! That’s the absolute beauty of HTMX—it completely decouples you from the JavaScript ecosystem and lets you leverage whatever backend you love. Delphi + HTMX sounds like an incredibly fast, compiled powerhouse. Love seeing unique stacks like this thriving!
so REACT is useless or not ?
It depends on the scale. For small sites, it's often overkill. For massive, state-heavy apps, it provides a structure that's hard to replicate with vanilla JS. It’s a tool, not a requirement.
Very nice 👍🏾 good job
Thankyou
Python is 90s language than why it booms in 2020s is it due to AI mainly ?
You are exactly right. While Python was created in 1991, its massive boom in the 2020s is heavily driven by the AI, machine learning, and data science explosion.
Because of its simple, readable syntax, data scientists and academics embraced it early on. This led to the creation of powerful C-optimized libraries like NumPy, Pandas, TensorFlow, and PyTorch. Python essentially became the ultimate "glue language"—allowing developers to write easy code that triggers lightning-fast, low-level C/C++ operations under the hood for heavy AI workloads. Its massive ecosystem and corporate backing solidified it as the undisputed standard for modern AI development.