Why HTMX is Enough, and the Direction of Front-End.

Disclaimer: brainpolo does utilise React for some frontends, but this is primarily out of deliberate tradeoff optimisation for a few reasons detailed below.

After sufficient exploration in building a wide range of frontends from simple static sites to mid-level interactivity such as blogs, to the other end of the spectrum with brainful with absurdly high levels of dynamism and component state complexity, it is sufficient to say that HTMX was and is wholly sufficient to create applications with any level of complexity. This is not to say that creating complex applications shouldn't be done in React-like dedicated frontend frameworks, but rather, that, to falsify the false notions that beginners and React-heavy developers tend to have.

1. Complexity can lead to stagnancy. Just because something is popular does not make it right.

In the React community, it seems it is the only thing every new developer is learning, whether it is because all the job roles specify it as a must-have skill, or it is the only thing plastered across all of social media that they're exposed to, it is evident the direction the community is taking, is heavily centered around React.

If one makes the argument that React is built for complex enough single page applications (SPA), that would be fair, but to promote it as a beginner level framework, or use it as the end-all, be-all universal framework for any project of any scope of any complexity, is plain wrong. Yet this is exactly what is seen being adopted by students and beginners entering web development.

Using an over-engineered solution for a problem is just as much of a problem as not creating the solution at all. Why is this a problem? When we over-engineer solutions, we end up with a misaligned perception of the tool, and diminishes our ability to iterate fast, and heightens the maintenance burden of the project as it requires a deeper understanding of the framework to leverage effectively and efficiently.

When you do over-engineer, you create tech debt; the net solution is a net negative in that it leaves a bigger problem than the solution to the problem itself. And this is why you often see many startups and businesses who adopt React, have very slow update and iteration cycles.

Mastering React is a lot more complicated than learning the fundamentals, and to think that one should learn TSX/JSX before HTML, JS, and CSS is ludicrous.

2. Using a powerful framework does not mean one cannot solve it better using a simpler framework - power != outcome

When the use of something more complex happens, it is often at the cost of proficiency in the tool or framework which leads to less than mediocre results by the majourity of those using that tool or framework, and it is those people that would often be better served by mastering something at a less advanced level.

3. Technology adoption is rarely based on software merit, but rather industry perception, backdoor enterprise deals, and sheep-herding of the economy into familiar existing environments.

In effect, the tech debt grows larger and larger, even if these companies do believe that they are in need of an imminent change in their tech stack simply because of the lag between labour ready expertise in the market for that tech stack AND the readiness and time of completion for the business to perform the migration. This is one of the most resource intensive endeavours any business can take.

Whilst companies claim that they are hiring for engineers that are tech-stack agnostic, this is largely only true for elite tech companies rather than the norm, especially in other industries, simply because the availability of such engineers is limited. Granted, this is increasing with greater competition and the higher availability of highly skilled engineers in the workforce, with the trend likely to continue to increase, it is still going to be a 'finding the needle in the haystack' problem. Even if companies over time change their hiring processes to look for tech-stack-agnostic engineers, there is no denying that an engineer who has been wholly trained on that tech stack will always outperform the engineer who is in the learning phase, before they even become economically productive against AI.

When Facebook (now Meta), introduced React in 2013, it was novel, and geniunely solved problems that there was no previous production-grade solution to build such solutions, and for many years, it was ideal. Whilst intercooler.js (former HTMX) did come around that exact time, it was not production-ready nor as far-reaching in visibility as Facebook's React. And all of the engineers who did adopt React at the time were wholly right to do so for anything requiring even moderate interactivity.

However, when HTMX officially released in 2022, things changed, because it allowed a completely new way to think about adding dynamism to applications. Instead of reinventing HTML or JavaScript with React's JSX/TSX, why not simply extend HTML's functionality to enable hypermedia experiences? This fundamentally changed the way software could be built, and winning in both learning curve and iteration speed.

4. Stopping too early kills growth.

Now, in 2025, we are still peddled towards React, and even the engineers who began in React have not moved on, or even considered trying HTMX, internally dismissing it as a 'less powerful' option without any rational justification. This is simply not true. If I asked random engineers what frontend was used to build brainful, nine out of ten times they would guess wrong and pick React, when rather, it is fully powered using HTMX, and some light JS. And ironically, the engineers who do live by React would have a hard time replicating the frontend complexity of brainful due to the exponentially greater learning curve and number of lines of code to replicate such functionality in React.

The ones who claim that HTMX is not sufficient, have simply not used it long enough to realise the elegance and power in its rather relative simplicity. They will spend ten hours with a drill a nail into a piece of wood when a hammer would have done the job in a fraction of the time and complexity. If everything had to be complex for it to be feasible, C would not be the mother of all modern programming languages, and the sheer possibility of complex software capable of being made would not exist. As Bruce Lee rightly said, "I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.", this is no different in programming, mastering a basic set of building blocks will unlock far more growth potential than trying something that attempts to master it all in bits and pieces.

Choosing the right tools is not just about outcomes, it is about developer experience, and more specifically, iteration velocity. React was built for large teams at Facebook and other enterprises, not individuals, startups, or simple applications with light interactivity.

What convinced me that AI is likely the silent killer of growth and has the greatest possibility to stifle innovation is when I noted the difference in using it to develop frontends using HTMX and server-side rendering (SSR), versus developing frontends using isolated React applications. It was a clear night and day difference, and goes against all intuition. It would intuitively make sense that AI would master a simpler library, but it turns out the opposite, it only masters what it is widely trained on, and that is, of course, React. All LLMs were always outperforming in producing excellent React frontends compared to HTMX, and even in cases where HTMX was a success, it was only with heavy human-driven guidance and intuition, whereas React was almost always success using entirely agentic processing.

This means, that even if there exist good libraries, frameworks, outside of the realm of the industry standard, given the abilities of AI, is what will largely govern what decision people will make, and this can have disasterous consequences in terms of the decision making that the software and broader impact CS will have in the future as a consequence of AI. There will be fewer incentives to using HTMX and other less-known libraries and/or frameworks simply because AI is excels at using a swiss army knife and even if another solution should be used in place, it would still take longer to achieve. This is effectively conflating our perception of the value of frameworks/tools based on its usage and popularity rather than the merits of the software.

In all, whilst React remains a pragmatic choice given economic realities, it is imperative to recognise the future economic cost of not implementing things the ideal way, and the potential implications of these decisions in the future. Every AI-accelerated shortcut today compounds tomorrow's technical debt, and the question isn't about whether to use React or not, it's about being cognizant of forseeing how these decisions will implicate future decisions, and making sure that what's being chosen is being chosen for the right reason, not simply because AI has learned to suggest it most often.