I want to make the intent of this blog post extremely clear (which tragically got lost when I got deep into the writing).
I love HTMX, and I've built entire sites around it. But all over the internet, I've seen HTMX praised as this pristine perfect one-stop-solution that makes all problems simple & easy (or at least... easier than any framework could ever do).
This is a sentiment I have not found to be true in my work, and even one where the author of HTMX spoke out against (although I can't find the link :(
It's not a bad solution (it's actually a very good solution), but in real production sites, you will find yourself scratching your head sometimes. For most applications, I believe it will make ALMOST everything simpler (and lighter) than traditional SPA frameworks.
But for some "parts" of it, it is a little tricker, do read "When Should You Use Hypermedia?" [1];
In the next blog post (where we'll be implementing the "REAL" killer features), I hope to demonstrate that "yes, HTMX can do this, but it's not all sunshine & rainbows."
---
On a completely separate note, one may ask, then, "why use HTMX?" Personally, for me, it's not even about the features of HTMX. It's actually all about rendering HTML in the backend with something like Templ [2] (or any type-safe html templating language).
With Templ (or any type-safe templating language), I get to render UI from the server in a type-safe language (Golang) accessing properties that I KNOW exist in my data model. As in, the application literally won't compile & run if I reference a property in the UI that doesn't exist or is of the incorrect type.
You don't get that with a middle-man API communication layer maintained between frontend and backend.
All I need now is reactivity, and htmx was the answer. Hope you understand!
I read through this and I don't get it. Recreating an entire form on the backend and swapping it with the current one, and then missing the update of the label status?
Then solving this by recreating the entire stepper html at each step, with the added complexity that if it contains something you want to keep "it's a nightmare"?
Then having to create a temporary server-side session to store data that somehow the browser can't keep between two clicks?
Etc.. it's write web apps like it's 1999.
junon · 1h ago
Also the title itself does a disservice to HTMX; wasn't it billed as sort of "modern frameworks are bloated and difficult, let's go back to Simple"?
fvdessen · 1h ago
HTMX is indeed simple and lean, but unfortunately that doesn't mean solving common frontend problems with HTMX is simple either. After a decade of frontend dev and being tired of react/vue/etc, I tried HTMX, wanting for something leaner, but IMHO it has big problems, and I am back to react/vue.
The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare.
The other is that the code of components is split in two, the part that is rendered on the first time, and the endpoint that returns the updated result. You need a lot of discipline to prevent it from turning that into a mess.
The final nail on the coffin for me was that the thing I wanted to avoid by picking HTMX; making a rest api to separate the frontend and the backend, was actually a good thing to have. After a while I was missing the clean and unbreakable separation of the back and front. Making the rest api was very quickly done, and the frontend was quicker to write as a result. So HTMX ended up slower than react / vue. Nowadays react/vue provide server side rendering as well so i'm not sure what Htmx has to bring.
withinboredom · 37m ago
> you need to put the whole app state in the URL and that quickly becomes a nightmare.
You should be doing this anyway ... it's so annoying when my wife sends me a link at work and it just goes to a generic page instead of the search results she wanted to share with me. She ends up mostly sending me screenshots these days because sharing links don't work.
Cthulhu_ · 31m ago
Depends on what the commenter means by app state. Anything bookmarkable - like search results - should be in the URL, but "state" should not (I consider things like partially filled in forms, shopping carts, etc to be state).
foobarbecue · 9m ago
Presumably you mean search query input, not search results, right?
chrisandchris · 26m ago
> HTMX is indeed simple and lean, but unfortunately that doesn't mean solving common frontend problems with HTMX is simple either.
Then it is not simple (as in simple I understand it) it's just the same we already have, reinvented.
If it would be simple and lean, it would solve the most common problems by itself (like I don't need to care about the HTTP part in .Net - it's a one liner and the framework solves it for me).
bookofcooks · 1h ago
Yes, this was what I wanted to get across with the article (although I utterly failed to do so). I think I would stick to HTMX for other reasons (which I've made clear in my top-level comment on this thread), but I now I see it an occasional tool to use for something simple and not long-term.
> The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare.
Or you can create a large session object (which stores all the state) on the server, and have a sessionId in the URL (although I'd prefer a cookie) to associate the user with that large session object.
jgalt212 · 46m ago
Server side rendering requires JavaScript on the server. So then you very often, but not always, violate "the clean and unbreakable separation of the back and front."
colejohnson66 · 13m ago
Not necessarily JavaScript, but some kind of rendering or templating engine. As shown in the blog post, Go works.
brokegrammer · 1h ago
I built my latest SaaS (https://clarohq.com) using HTMX, backed by Django. I really enjoy the process because HTMX allows reactivity using swaps and plain Javascript events instead of server side state management, useeffect, and API endpoints.
However, it's difficult to get things right. I spent way too much time on some basic features that I could have shipped quicker if I used React.
The issue with React though, is that you end up with a ton of dependencies, which makes your app harder to maintain in the long-term. For example, I have to use a third-party library called react-hook-form to build forms, when I can do the same thing using plain HTML and a few AlpineJS directives if I need dynamic fields.
I'm not sure if I'll ever build an app using HTMX again but we need more people to write about it so that we can nail down patterns for quickly building server rendered reactive UIs.
zarzavat · 53m ago
> For example, I have to use a third-party library called react-hook-form to build forms
Why? I've written a lot of React and I've never used this library. In fact, I rarely use any React-focused dependencies except a router, as you say every dependency has a cost especially on the client.
React works just fine without dependencies.
bloomca · 19m ago
What kind of forms do you need? I honestly feel people think they have to use all sort of dependencies. There are some you definitely need, like the router or any state management (you can build both, but there is a decent amount of boilerplate and efficient hooks can be tricky).
But for forms I honestly would recommend to start with plain React and only abstract things you need in your project.
threatofrain · 1h ago
You only use the popular React form libraries when you want utmost control over your forms. Like as you type into a registration form you check off boxes for password requirements, and you only show errors after they’ve touched it once.
Otherwise vanilla forms are great in React. If you did this by hand in Vue or vanilla it would also be hell.
Also in terms of maintenance burden the top libraries in this space are massively popular. Most here would likely be making a great maintenance burden decision in offloading to well reputed teams and processes rather than in housing your own form and validation library.
brokegrammer · 57m ago
Sure, I could build forms with React only but I found controlled forms to have less performance when there are many fields. react-hook-forms uses uncontrolled forms with refs which has near native performance, so if I had to build that by hand it would be more tedious. AI makes this process easier, but it's still extra code that needs to be maintained and tested, when you can do the same for free if you stick with standard web tools.
bookofcooks · 1h ago
Exactly my idea.
This Github demo was pulled straight out of some work I was doing for the Admin of Prayershub (https://prayershub.com).
Working on this specific feature (the soundtrack uploader) though, I reguarly asked myself "what if I just used Svelte or SolidJS"?
Note, Prayershub uses a regular mix of HTMX and SolidJS, so I can pop-in SolidJS whenever I find convenient.
brokegrammer · 54m ago
I've been thinking about loading React or something similar for specific components but still not sure which method I'm going to use for that. How are you embedding SolidJS on specific pages? Or do you actually have a full build pipeline?
pbowyer · 17m ago
I do this with Vue in Symfony PHP apps. Depending on the scope I eitehr have a full build pipeline for the JS (preferred) or will include the files direct from a CDN and have in-HTML templates that are parsed on load.
For passing data into it I've used Inertia.js [0] and also my own data-in-page setup that's parsed and loaded into the Vue app. The app then writes the changes back out, usually into a hidden form input. The form on the page is then submitted as usual to the server, along with any other data that I need.
It's a great way for adding more complicated behaviour to an existing app.
Now, how I specifically embed SolidJS, its pretty simple, I have my entrypoint files for specific pages:
assets/admin-edit-book.tsx
assets/admin-edit-song.tsx
assets/single-worship.tsx
assets/worship-edit.tsx
Then I have a 30-line build script that invokes esbuild along with esbuild-plugin-solid (to compile JSX to plain-old html, no fancy virtual dom) to compile the scripts into javascript.
I can share the build script if you'd like. It helps that SolidJS is so self-contained that it makes such a setup trivial.
worble · 57m ago
> I have to use a third-party library called react-hook-form to build forms
Regular form elements work just fine in React, all you need to do is interrupt the onInput and onSubmit handler and deal with the form data yourself. I've tried a handful of these form libraries and frankly they make everything way more complicated and painful than it needs to be.
bestest · 17m ago
That is fine as long as your forms are simple text inputs and buttons. Now plug in drag-and-drop and multiple file uploads and selects and checkboxes and radios and more of these various inputs you're in the world of pain.
I've recently, once again, gave native inputs a chance in a new project. It lasted as long as I've described in the first sentence. And I've been in the frontend world for 20 years. Trust me, you don't want complicated native forms.
And react-hook-form is just what you need (albeit it also is boilerplate-ish, so I always end up wrapping it up in a simpler and smarter hook and component).
edit: Same, in a sense, for HTMX. It's ok for simple things. But eventually you may end up trying to build a house with a fork. The fork in itself is not a bad tool, sure. But you also don't need a concrete mixer with your morning toast.
alex-moon · 3h ago
These kinds of write-ups are so key to driving adoption of a new technology. I'm still not super interested in HTMX but this write-up has done a lot of the work already toward nudging me that way. Well done!
rapnie · 1h ago
Yes, as I remember it it was a 'back to simplicity' of the early web idea. Rediscover the power of hypermedia. I don't know HTMX well, but am following Datastar [0] which was inspired by it, and their selling points are Simplicity and Performance and take it some steps further than HTMX. The approach does shift logic / complexity towards the backend though.
Unrelated: datastar doesn't use a two-way connection for interaction <-> updates. It uses two unconnected one-way channels: a long-lived long-lived SSE for updates, and new HTTP requests for interaction.
I didn't see guidance in the docs for routing one tab's interaction events to the backend process managing that tab's SSE. What's the recommend practice? A global, cross-server event bus? Sticky sessions with no multiprocessing, and an in-process event bus?
If a user opened the same page in two tabs, how should a datastar backend know which tab's SSE to tie an interaction event to?
devnull3 · 12m ago
With DS (and HTMX) the backend is the source of truth. In the context of the blog post, the state will be made-up of: step no, file content, file path, etc. This can be stored against the session ID in a database.
So when opened on a different tab, the backend would do authentication and render the page depending on the store state.
In general, the backend must always compare the incoming state/request with stored state. E.g the current step is step 2 but the client can forces it to go to step 4 by manipulating the URL.
DS v1.0 now supports non-SSE (i.e. simple request/response interaction as well) [1]. This is done by setting appropriate content-type header.
In DS, with SSE you can paint different parts of the page with ease. So in this case, it can update <form> and <label> separately. So instead of one update the backend fires 2. There is not separate marker or indicator for OOB.
I think it is best seen in examples on DS website.
Polarity · 1h ago
> I originally planned to make a simple non-functional uploader, then progressively bring it from "it works™" to "high-quality production-grade Uploader with S3 Presigned, Multipart, Accelerated Uploads, along with Auto-Saving and Non-Linear Navigation
Why is every developer trying to make things complicated?
Cookies are more appropriate for whole-site or whole-session data. There's no natural segregation of "this cookie belongs to this instance of this form". You could figure that out, but the additional moving parts cut down on the appeal.
bookofcooks · 1h ago
You can... I guess.
karel-3d · 1h ago
Every time I attempt to use HTMX and backend-rendered templates because it's "simpler", in the end I always end up doing JSON APIs and something like Svelte. Because all the "simplicity" explodes in complexity 5 seconds later, and it's very user-hostile with the constant reloads.
This blogpost affirms it
kissgyorgy · 1h ago
This implementation is unnecessary complicated. For the step update, you can use Out Of Band update: https://htmx.org/attributes/hx-swap-oob/ which works in a way that you can send multiple HTML fragments which can be anywhere on the page and HTML swaps them out. Good for notifications, step update, breadcrumb update, menu highlight, etc...
I usually solve the second problem by simply saving the state of the individual input fields, you only need a user session.
Depending your use-case, you might need to be transactional, but you can still do this saving everything as "partial" and close the "transaction" (whatever it might mean in the given context) at the last step. Much-much simpler than sending form data over and over.
bookofcooks · 57m ago
> For the step update, you can use Out Of Band update
I did mention using OOB, but I preferred swapping the entire Stepper because the logic on the backend was just a little bit cleaner, and the Stepper didn't include anything else anyways.
> I usually solve the second problem by simply saving the state of the individual input fields, you only need a user session.
I believe this is exactly what I did in the article, no?
rtpg · 1h ago
that form state persistence looks soooo gnarly. Really have a hard time arguing that's better than a client side header
totaa · 2h ago
congrats on the first blog post, been using Go+Templ+HTMX when implementing my first startup
I think at least some of these issues can be avoided with a different UI/UX to avoid passing temporal/unsaved data between screens.
looking forward to the next instalment!
andrewstuart · 1h ago
All that seems rather ….. indirect. Every step of the way I kept urging him to use JavaScript.
lmz · 1h ago
They could have done all that in one long form with JS for client side progressive enhancement (show/ hide different parts) and that would probably be much easier.
graeber_28927 · 31m ago
Yes, my thoughts exactly. I hate implementing N forms with user state session and navigation, when one big form one the client can hold the state for me, and visual trickery can achieve the same.
Whenever I go debug unnecessary state machines, or have to refactor them (to compress the number if steps), I scratch my head half the time, trying to follow the string of thought that my predecessor felt so smart about.
I want to make the intent of this blog post extremely clear (which tragically got lost when I got deep into the writing).
I love HTMX, and I've built entire sites around it. But all over the internet, I've seen HTMX praised as this pristine perfect one-stop-solution that makes all problems simple & easy (or at least... easier than any framework could ever do).
This is a sentiment I have not found to be true in my work, and even one where the author of HTMX spoke out against (although I can't find the link :(
It's not a bad solution (it's actually a very good solution), but in real production sites, you will find yourself scratching your head sometimes. For most applications, I believe it will make ALMOST everything simpler (and lighter) than traditional SPA frameworks.
But for some "parts" of it, it is a little tricker, do read "When Should You Use Hypermedia?" [1];
In the next blog post (where we'll be implementing the "REAL" killer features), I hope to demonstrate that "yes, HTMX can do this, but it's not all sunshine & rainbows."
---
On a completely separate note, one may ask, then, "why use HTMX?" Personally, for me, it's not even about the features of HTMX. It's actually all about rendering HTML in the backend with something like Templ [2] (or any type-safe html templating language).
With Templ (or any type-safe templating language), I get to render UI from the server in a type-safe language (Golang) accessing properties that I KNOW exist in my data model. As in, the application literally won't compile & run if I reference a property in the UI that doesn't exist or is of the incorrect type.
You don't get that with a middle-man API communication layer maintained between frontend and backend.
All I need now is reactivity, and htmx was the answer. Hope you understand!
[1] https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-h...
[2] https://templ.guide/
Then solving this by recreating the entire stepper html at each step, with the added complexity that if it contains something you want to keep "it's a nightmare"?
Then having to create a temporary server-side session to store data that somehow the browser can't keep between two clicks?
Etc.. it's write web apps like it's 1999.
The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare.
The other is that the code of components is split in two, the part that is rendered on the first time, and the endpoint that returns the updated result. You need a lot of discipline to prevent it from turning that into a mess.
The final nail on the coffin for me was that the thing I wanted to avoid by picking HTMX; making a rest api to separate the frontend and the backend, was actually a good thing to have. After a while I was missing the clean and unbreakable separation of the back and front. Making the rest api was very quickly done, and the frontend was quicker to write as a result. So HTMX ended up slower than react / vue. Nowadays react/vue provide server side rendering as well so i'm not sure what Htmx has to bring.
You should be doing this anyway ... it's so annoying when my wife sends me a link at work and it just goes to a generic page instead of the search results she wanted to share with me. She ends up mostly sending me screenshots these days because sharing links don't work.
Then it is not simple (as in simple I understand it) it's just the same we already have, reinvented.
If it would be simple and lean, it would solve the most common problems by itself (like I don't need to care about the HTTP part in .Net - it's a one liner and the framework solves it for me).
> The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare.
Or you can create a large session object (which stores all the state) on the server, and have a sessionId in the URL (although I'd prefer a cookie) to associate the user with that large session object.
However, it's difficult to get things right. I spent way too much time on some basic features that I could have shipped quicker if I used React.
The issue with React though, is that you end up with a ton of dependencies, which makes your app harder to maintain in the long-term. For example, I have to use a third-party library called react-hook-form to build forms, when I can do the same thing using plain HTML and a few AlpineJS directives if I need dynamic fields.
I'm not sure if I'll ever build an app using HTMX again but we need more people to write about it so that we can nail down patterns for quickly building server rendered reactive UIs.
Why? I've written a lot of React and I've never used this library. In fact, I rarely use any React-focused dependencies except a router, as you say every dependency has a cost especially on the client.
React works just fine without dependencies.
But for forms I honestly would recommend to start with plain React and only abstract things you need in your project.
Otherwise vanilla forms are great in React. If you did this by hand in Vue or vanilla it would also be hell.
Also in terms of maintenance burden the top libraries in this space are massively popular. Most here would likely be making a great maintenance burden decision in offloading to well reputed teams and processes rather than in housing your own form and validation library.
This Github demo was pulled straight out of some work I was doing for the Admin of Prayershub (https://prayershub.com).
Working on this specific feature (the soundtrack uploader) though, I reguarly asked myself "what if I just used Svelte or SolidJS"?
Note, Prayershub uses a regular mix of HTMX and SolidJS, so I can pop-in SolidJS whenever I find convenient.
For passing data into it I've used Inertia.js [0] and also my own data-in-page setup that's parsed and loaded into the Vue app. The app then writes the changes back out, usually into a hidden form input. The form on the page is then submitted as usual to the server, along with any other data that I need.
It's a great way for adding more complicated behaviour to an existing app.
0. https://inertiajs.com/
For other page, I'll use full-blown SolidJS (with JSX and everything) for like a popup. Example: https://pasteboard.co/hY35xM7VbATG.png
Now, how I specifically embed SolidJS, its pretty simple, I have my entrypoint files for specific pages: assets/admin-edit-book.tsx assets/admin-edit-song.tsx assets/single-worship.tsx assets/worship-edit.tsx
Then I have a 30-line build script that invokes esbuild along with esbuild-plugin-solid (to compile JSX to plain-old html, no fancy virtual dom) to compile the scripts into javascript.
I can share the build script if you'd like. It helps that SolidJS is so self-contained that it makes such a setup trivial.
Regular form elements work just fine in React, all you need to do is interrupt the onInput and onSubmit handler and deal with the form data yourself. I've tried a handful of these form libraries and frankly they make everything way more complicated and painful than it needs to be.
I've recently, once again, gave native inputs a chance in a new project. It lasted as long as I've described in the first sentence. And I've been in the frontend world for 20 years. Trust me, you don't want complicated native forms.
And react-hook-form is just what you need (albeit it also is boilerplate-ish, so I always end up wrapping it up in a simpler and smarter hook and component).
edit: Same, in a sense, for HTMX. It's ok for simple things. But eventually you may end up trying to build a house with a fork. The fork in itself is not a bad tool, sure. But you also don't need a concrete mixer with your morning toast.
[0] https://data-star.dev
In datastar the "Out Of Band" updates is a first class notion.
[1] https://data-star.dev
I didn't see guidance in the docs for routing one tab's interaction events to the backend process managing that tab's SSE. What's the recommend practice? A global, cross-server event bus? Sticky sessions with no multiprocessing, and an in-process event bus?
If a user opened the same page in two tabs, how should a datastar backend know which tab's SSE to tie an interaction event to?
So when opened on a different tab, the backend would do authentication and render the page depending on the store state.
In general, the backend must always compare the incoming state/request with stored state. E.g the current step is step 2 but the client can forces it to go to step 4 by manipulating the URL.
DS v1.0 now supports non-SSE (i.e. simple request/response interaction as well) [1]. This is done by setting appropriate content-type header.
[1] https://data-star.dev/reference/actions#response-handling
[0] https://htmx.org/attributes/hx-swap-oob/
I think it is best seen in examples on DS website.
Why is every developer trying to make things complicated?
Why not use cookies?
This blogpost affirms it
I usually solve the second problem by simply saving the state of the individual input fields, you only need a user session. Depending your use-case, you might need to be transactional, but you can still do this saving everything as "partial" and close the "transaction" (whatever it might mean in the given context) at the last step. Much-much simpler than sending form data over and over.
I did mention using OOB, but I preferred swapping the entire Stepper because the logic on the backend was just a little bit cleaner, and the Stepper didn't include anything else anyways.
> I usually solve the second problem by simply saving the state of the individual input fields, you only need a user session.
I believe this is exactly what I did in the article, no?
I think at least some of these issues can be avoided with a different UI/UX to avoid passing temporal/unsaved data between screens.
looking forward to the next instalment!
Whenever I go debug unnecessary state machines, or have to refactor them (to compress the number if steps), I scratch my head half the time, trying to follow the string of thought that my predecessor felt so smart about.