| 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. |
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.