Any time someone shows only HTMX examples without error handling I feel like they have not tried it in an actual use case. To me it feels non-obvious how to handle these non-happy-path things without having to write client-side code which is what I understood HTMX promised to do away with.
In the traditional browser model that HTMX espouses to emulate and improve on we have form resubmitting (with a warning that it will resubmit data), we have different errors for if the server returns an error or if your wifi disconnected, etc. Those errors are perhaps not well designed, but they are there and explain what is happening. With HTMX (at least when I tried it) it just got swallowed and one had to write client side code to handle it.
I think it's a little more accurate to say that htmx lets you handle the common cases with client-side attributes, so that you only have to bust out the client-side scripting in rarer cases.
You're definitely correct that the htmx documentation and tutorials and such don't talk about error-handling as much, and that should change! This is partly a function of how relatively young htmx is, and how long its been since the industry focused on hypermedia-related error handling patterns, so I'm optimistic this won't be the case for too much longer.
In the meantime, what I usually do is write a tiny htmx config snippet that intercepts 4xx or 5xx responses, and inserts them as a modal/popup/alert in the DOM. You can also do the opposite, and hook into an event from before the request, and do something with it if the requests fails for other reasons. Another common pattern is to return an error modal from the server and target the "error" spot in the DOM. There are also extensions for handling different response codes differently.
But again, while it's very do-able and I think reasonably intuitive once you start building larger apps with htmx, it's still an undeveloped aspect of the educational materials :)
To be fair most framework and library examples or showcases never show the error handling or edge case pieces so I don't think it's unusual.
htmx doesn't promise to do away with client side code. Most uses of it I see still have client side code. They tend to go in one of two directions with it.
1. Web Components to encapsulate client side error handling and behavior.
2. The hx-on attribute for scripted event handling.
It's not really an anti Javascript library. It's more of a different approach to server side state synchronization.
I have to dynamic apps I use for personal usages. One is an offline first spa app so htmx won't work well for it. It's all client side code with json apis. The other has no offline use case and htmx is a great fit for it but I still have several hundred lines of vanilla javascript in there for client side behavior bits.
HTMX does not promise to "do away with" client-side code. In many cases, you don't need or need significantly less JavaScript in an HTMX codebase than in other alternatives, but the point is not to use no JavaScript, but rather to extend HTML to do what JavaScript shouldn't be needed for. Its error handling story could be better in a number of ways, but it isn't a promise break.
I couldn't agree more. Without showing specific approaches for handling errors, there is too much uncertainty around whether or not htmx is actually a good approach. It doesn't matter how rare an error is. They happen and have to be addressed.
What happens, for instance, if the the request times out?
Also, the main reason, I feel, for actually wanting to use react is if you have an application with data that has a complex relationship with the UI. I don't know the technical term for this unfortunately, but the idea is that state management through, say, redux allows data changes to propagate throughout the UI. HTMX doesn't appear to address this at all. In fact, it seem like very brittle relationships between htmx elements are established. It is equivalent to a jquery + id nightmare.
How errors are handled is often pretty specific to each use case.
Sometimes it does make sense to send back an HTML fragment with an inline error message, or a fragment that gets injected as a toast notification. Other times you may want to redirect to an error page with a full page refresh. Depending on the HTTP request method used, you may be able to return an HTTP error response too.
Go to https://htmx.org/reference/#events and find in page 'error'. You will see all the different error events that htmx lets you hook into and handle. Don't be fooled by its apparent simplicity. It's very carefully designed.
There are different sorts of errors with respect to htmx:
1) application errors (e.g. bad data in a form)
These should be dealt with the "normal" way: rerender the form with error messages on them. Most good server side frameworks w/ form integration make this easy, and you can see an example of that here:
These are things like 500-level errors, 404s, etc. In this case htmx does not swap by default, but you can modify that behavior if you'd like to have it swap (and retarget, etc.)
3) network errors
On network errors, htmx triggers events such as htmx:sendError, that you can handle and show an error message, etc.
By and large we get almost no support issues around error handling: it is fairly obvious how to make things work if you are familiar with traditional web applications and more complicated things like connectivity issues are handleable via events, which isn't complicated either.
One thing that does occasionally bite people is when server-side frameworks respond with a 422 response code for application-level errors and try to rerender a form with those error messages. By default htmx will not swap that response since it is not a 200-level response code. You can modify this behavior here:
If I had it to do over again, I would consider making 422 responses swap by default.
Regarding the "resubmit" warning, that doesn't apply to htmx-powered applications because AJAX operations don't naturally end up in the history chain. This means that the Post-Redirect-Get pattern isn't needed.
Error handling isn't a particularly hard aspect of htmx. What is hard is adjusting your mindset to the hypermedia approach, particularly if you are very deep into reactive programming. And there are applications that this approach is not suited for:
In the traditional browser model that HTMX espouses to emulate and improve on we have form resubmitting (with a warning that it will resubmit data), we have different errors for if the server returns an error or if your wifi disconnected, etc. Those errors are perhaps not well designed, but they are there and explain what is happening. With HTMX (at least when I tried it) it just got swallowed and one had to write client side code to handle it.