Last year I spent forty minutes setting up a React project for an internal admin dashboard. Just the boilerplate. Vite config, ESLint setup, Tailwi...
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.
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.
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 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?
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.
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 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.
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.
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.
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.
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
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 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.
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.
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.
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
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.
Now i am thinking to explore python after reading this
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 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.