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:
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:
https://htmx.org/examples/inline-validation/
2) server errors
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:
https://htmx.org/docs/#modifying_swapping_behavior_with_even...
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:
https://htmx.org/essays/when-to-use-hypermedia/
However, when your application is well suited for the approach, htmx (or similar approaches) can be a very big win:
https://htmx.org/essays/a-real-world-react-to-htmx-port/