Why htmx sucks. And why it doesn't.

There's been a lot of hype recently around htmx, especially among backend devs. And if you read Reddit comments you will see both sides, some folks seem to think htmx is the best thing that has happened in web dev while others consider it a complete garbage. 

I have been following htmx for a while now and I feel like htmx is misunderstood. As with any tool, there is a correct way to use it and a way to misuse it.

Let's begin by looking at some reasons why you shouldn't use htmx aka why it sucks.

#Why htmx sucks

htmx is not a frontend tool.

That's right. htmx is a tool for backend devs not for frontend devs. It is a not a frontend framework and people should not be using htmx to build user facing apps. It simply isn't made for this purpose.

#The code is garbage

If you look at htmx code you will see that it is ... well, let's just say you won't find best programming practices here. 

The use of var all over the place, almost no modern JavaScript features (hello, htmx people, no ESM Modules), polluted window namespace, and on and on and on.

Let's be fair - it’s just one big ball of JavaScript mess! Everything gets written more or less in one JavaScript file. You would not pass Computer Programming 101 class writing code like this. Forget about SOLID, separation of concerns, DRY principles. Good software starts with clean code, and this code is filthy.

But you know what? That's ok! It's ok because htmx isn’t trying to win any awards for code elegance or best practices. Its primary goal is to make it incredibly easy for backend developers to add interactivity to their web applications without having to dive deep into frontend frameworks or JavaScript intricacies. The messy code is a trade-off for the simplicity and accessibility it offers.

#No Build Tools

You will notice that there are no build tools involved in htmx. No npm. No node_modules. And that's by design. Not only does htmx not have a traditional build step, (you won't have the benefits that the rest of the JavaScript community enjoys), but they actively brag about it! If you look closely, even though they claim to not have a build step, they actually do have a build step, it’s just an ad hoc set of bash scripts they wrote themselves.

But the reality is that backend developers don't need or want to mess with complex frontend build tools. If you are going to be creating very simple pages - you don't need build tools.

#No JavaScript, no interactive UIs

htmx is primarily meant to be used for static webpages. It is meant to lift the burden of dealing with JavaScript and JS libraries off the shoulders of backend developers who don't want or care about dynamic / interactive UIs. This means you won't be banging out the best UI / UX / interactive / dynamic frontend apps with htmx. You won't be able to create the next Facebook, Google Maps or Figma with htmx - it simply isn't meant for modern frontend developement. If you care about user experience - htmx is not for you.

#No TypeScript

Despite the obvious benefits of TypeScript the htmx authors have resisted using it. Part of this is their opposition to a build step but part of it is a  commitment to “shipping debuggable source code”. Of course, as any JavaScript developer knows, TypeScript supports Source Maps that make it perfectly debuggable. TypeScript also reduces bugs in your codebase by 40% just by installing it. Despite this fact, the authors continue to insist on using plain old JavaScript which can make it very difficult to work with on a larger project.

#Antiquated Technology

The authors of htmx have decided upon using hypermedia. It's ... simple. Yes, it means you will be sending 10x as much code via HTTP requests. That might be ok if the project is very simple and not user facing. Shh, nobody will even know! This is not anything new: intercooler.js, PJax and Unpoly (even better than htmx) have been around literally forever.

Even before that, we had jquery.load().

Look at this jQuery code from 2008:

$( "#result" ).load( "ajax/test.html" );

And now look at the super innovative stuff the htmx folks give us:

<button hx-get="/ajax/test.html"
        hx-target="#result">
    Load
</button>

Wow. Amazing.

Yes, I know I'm being sarcastic here but that's the whole point. Why not write everything in one file, without types, sending HTML chunks if you're a backend dev throwing together a simple UI?

#No Components

The next reason not to use htmx for a modern frontend app is that there aren’t any components available for it. It simply doesn't have components. If you go with React or Vue you get things like MUI, NextUI & Chakra.

With htmx, you get… nothing. You have to figure out what components you need and create them yourself and integrate them with htmx using events and so forth.

Yes, it really sucks from a frontend developer perspective. But htmx is not for frontend developers. And backend developers have never really been into components anyway. So for very simple pages - you might not need components at all.

#No frontend/backend separation

Another major reason to avoid htmx if you are building a serious frontend app is that it eliminates the separation between the backend & frontend. Separating the backend from the frontend allows independent teams to move forward very quickly, focusing on creating great user experience and allowing the backend devs to focus the logic and data access layer.

Technologies like GraphQL and RSC are especially helpful allowing the frontend developers to effectively communicate with the backend without understanding backend frameworks. This has proven to be a very good organizational model for companies, particularly as they scale their development teams.

#Backend Engineers Make Garbage UIs

Just look at the htmx website. You’ve got inline styles, tables, a bunch of image tags didn’t have alt descriptions forever. Just a dogs breakfast of bad HTML, from people who are trying to tell us to use HTML! Backend devs should leave the user interface and user experience in the hands of people who understand how to properly build them, and those people are, today, mostly frontend developers and designers.

#Duplicating Your APIs

Another reason why you should not choose htmx when building a large scale, user-facing app is the duplication of code. What happens if you also need to build a mobile app? And API? You cannot simply reuse your existing GraphQL API. You need to create new endpoints for that. It makes far more sense to have a single API maintained by a single, backend team that can flexibly serve all your needs.

#It Won’t Scale - and that's ok?

Another technical issue with htmx is that it just won’t scale. It may work for small applications, but as applications get larger the htmx model breaks down and becomes a mess. The component model of React/Vue/Angular and other frontend tools keeps everything compartmentalized and testable. This makes it much easier to keep large codebases clean.

As an example, consider Github, which started out using technology a lot like htmx. It has recently started adopting React and is now much more stable than it was previously. They would have been better off if they had just started with React and built the whole thing in a modern, component-based way, but at least they are making the right move now. 

Now let's look at some of the reasons why htmx does NOT suck.

Why htmx does NOT suck.

#Enables backend devs to create simple UIs.

Not every app needs a pretty UI or even UX. Sometimes you just need to create a basic webpage and this is where htmx shines. It allows backend devs who might not be familiar with frontend to create very simple UIs very quickly. That could be a simple admin panel for an internal tool or simply a way to get a few buttons on the page. htmx is perfect for that. Backend devs don't need to learn a frontend framework to create a basic UI.

#No JavaScript knowledge required.

It's no surprise that backend devs and JavaScript aren't the best of friends. And htmx does not require you to know any JavaScript. This is not an issue if you need a very simple frontend that is not public-facing. Not everyone is building the next Airbnb or Facebook. If your page does not need to be published on the internet then you might not need JavaScript at all.

Simplicity.

htmx allows backend devs to create UIs very quickly and simply. There are no modules to install. No JavaScript to wrestle with. No buggy frontend libraries. If all you need is a page with a few simple forms then htmx is perfect.

Lightweight and performant.

htmx is lightweight and adds a very minimal overhead to the project, ensuring fast load times and a responsive user experience without the bloat of larger frameworks.

So this is where htmx really shines. It enables backend developers to work on the frontend. They don't need fancy UIs or good user experience. All they want is to get some inputs and buttons on the page and perform simple actions. This is where htmx does NOT suck.

#Conclusion

At the end of the day, you should use the right tool for the job. If you are a backend developer needing to create very simple UIs then htmx is the right tool for the job. Your code doesn't need to scale, be clean or organized. Htmx allows your code to be garbage.

If you are creating a modern user-facing app that you plan to put out there on the internet for other people to use and you care about UI and UX - you should choose a modern frontend framework (Next.js / Nuxt). It will make your job as a developer much easier and make your users happy!