I was able to find architectural patters that work smooth as glass.
Here is what my htmx apps have: - Single-purpose endpoints: Each endpoint returns ONE thing (a card list, a tag cloud, a form fragment) - Optimistic UI: Preferences like font/theme update the DOM immediately; the save is fire-and-forget with no response needed - Simple error handling: Most endpoints either succeed (return HTML) or fail (HTTP error code) - No fragment orchestration: Not returning 3-5 fragments; using hx-swap-oob sparingly
Here is how I update fonts on screen in user prefs: User selects font → JS updates body class immediately → htmx.ajax() saves in background → done
vs. the anti-pattern you're describing:
User submits form → backend validates → returns success fragment OR error fragment OR partial update OR redirect signal → frontend must handle all cases
No language or programming paradigm is perfect. All programming is an exercise in tradeoffs. The mark of a good CTO or architect is that ability to draw out the best of the technology selection and minimize the tradeoffs.
How do you handle HTTP errors?
Just curious because when I used HTMX I didn't enjoy this part.
I have never loved the idea of the server rendering HTML which is probably why I have such a hard time with HTMX. In every other paradigm you clearly separate your server API and UI rendering/logic. Web apps are the only place where it seems common to have the server render UI components. Imagine if you had a Java or Swift application and had the server sending your phone UI screens. I don’t even know how you would pitch that. About the only thing I have seen that makes some sort of sense here is video game rendering to be able to play on really limited devices with quick internet access.
The problem with SPAs is the ecosystem. I recently found packages like this [1] and this [2] in my node_modules and that is insanity. But the architecture honestly makes way more sense than any other paradigm: server side is a well defined API and the client renders UI and handles local state.
Please do a write up of the best practices you've found. I tried htmx a few years ago for a side project and while I appreciated the simplicity of a lot of it, I had trouble understanding how/when to use it and in what ways. I think I was trying to contort it too much into my understanding of api/spa. That or my interactivity needs were too complex for it, I can't tell.
These days, I admit, though, the ship has sailed for me and htmx. My main app frontend is React and since the LLMs all know much more than I do about how to build out UIs and are 100x faster than me, I'll probably be sticking with React.