DEV Community

Cover image for HTMX or React? Why I chose a Third Way
Kevin 心学
Kevin 心学

Posted on

HTMX or React? Why I chose a Third Way

If you've been following web development news lately, you couldn't have missed the great debate of the moment. On one side, the ever-growing complexity of the modern JavaScript ecosystem (React, hooks, hydration, state managers, bundlers...). On the other side, the liberating promise of HTMX: a return to the roots, to HTML, hypermedia, and server-side rendering.

Many developers feel a genuine sense of relief when discovering HTMX. Goodbye JS bloat, hello simplicity.

But there's a catch.

HTMX is incredible for dashboards, back-offices, or classic CRUD applications. But what happens when your project requires a highly rich interface? Complex drag-and-drop, nested workflows, heavy data visualization, offline-first UI... In these cases, hypermedia minimalism is no longer enough. You need a real client-side application runtime.

Does that mean we have to resign ourselves to diving back into the chaos of classic frontend development, with its unstable dependencies, runtime errors, and "15 different ways to do the exact same thing"?

Fortunately, no. There is a "third way".

Breaking Out of the "Simplicity vs. Power" Compromise

The permissive JS ecosystem often gives an illusion of ease at the start, but quickly turns into massive technical debt at scale. We end up piling on glue code, fragile team conventions, and defensive testing just to keep everything from collapsing.

In stark contrast, PureScript brings the rigor of pure functional programming, and Halogen is its flagship UI framework. This is only one example among many. One possibility among many. But this duo has been the great gift for me. It offers a radically different philosophy:

  1. Extremely strong typing: Types aren't just optional annotations; they genuinely model your business domain.
  2. Controlled effects: No more hidden side effects buried deep inside a component. Everything is explicit.
  3. Declarative UI based on state machines: Halogen components look like rigorous, predictable state machines.

The Myth of "Bloat" and the Elegance of Compactness

People often confuse "amount of JavaScript shipped" with "amount of complexity expressed". Detractors of Single Page Applications (SPAs) rightfully denounce "bloat". But in many modern React projects, a lot of this noise comes from indirect state management (wrappers, providers, multiple hooks, context plumbing...).

With Halogen, what you code is minimalist, compact, and clear. The architecture naturally pushes you toward a certain discipline. Because the compiler eliminates the need for defensive coding and because abstractions are highly composable, you can express very sophisticated behaviors with very few lines of code.

"Yeah, but the learning curve..."

Today, Artificial Intelligence has completely changed the game.

AI acts as a permanent "FP pair programmer". It can translate a complex functional concept into concrete intuition, explain a tricky type error, or suggest idiomatic refactors. The barrier to entry has collapsed. Moreover, FP culture has become much more mainstream (immutability, pattern matching, pure functions); landing in an ecosystem like PureScript is no longer as alien as it was a few years ago.

Finding Calm and the Joy of Coding Again

What PureScript and Halogen have brought me, beyond technical robustness, is a profound sense of calm and serenity.

Yes, you read that right. Think about it for a minute. When was the last time you felt completely fulfilled after a day of coding: no headaches, no neck pain, no mental strain, no time pressure, and so on? For the vast majority of us, there’s a little voice inside that knows the truth. And it’s not a pretty sight. So, when a language... no, a framework... no... a parallel universe presents itself to you... maybe it’s worth taking a look. Because it really is a parallel universe.

By shifting problems from runtime to compile-time, and from social team conventions to the type system, cognitive load drops drastically. Your brain spends much less time fearing regressions or trying to anticipate impossible states. Much much less. Actually... near zero. Because it's a Hindley–Milner type system, here. Very good for safety.

Every type tells a story. Component boundaries are crystal clear. Massive refactors become not only safe but just... fun (again). The system feels like it’s collaborating with you, like an uncompromising but benevolent design partner, rather than fighting against you.

Of course, what I'm saying applies to other frameworks as well. Angular has made enormous progress. Svelte is excellent (etc.). Halogen is not the single source of relief.

And... HTMX and React can, of course, be the right solution if your constraints and preferences justify it. I'm not saying they’re obsolete. Far from it. That would be comtemptuous (I've also been a huge fan of React for years). I'm rather saying that the debate has been reduced to a perhaps overly simplistic dichotomy, even though it reflects a real tension and genuine constructive criticisms that can be made about these technologies. And I've proposed here an alternative path that has worked for me (and for others too: you'll notice it quickly).

You don't have to choose between simplicity and exhaustiveness, between conciseness and maximizing the potential of your tools. The third way exists. It requires a small initial effort, but the joy and peace of mind it offers in return are priceless.

Ok. I've said by piece now.

All the best!

Top comments (0)