SwapNavigation, URL State, And Progressive Enhancement With HTMX
Partial page updates are only a win if the application still behaves like the web.
Users expect the back button to work. They expect URLs to mean something. They expect a bookmark to restore the screen they were looking at. If those expectations break, the app feels clever in the wrong way.
Let routes remain real routes
One of the simplest rules for server-driven UI is also one of the most important: the route should still represent the screen.
HTMX is there to improve the interaction model, not to replace the navigation model.
That means:
- GET routes should still return meaningful screens,
- partial updates should line up with real navigable URLs where appropriate,
- filters and paging should not become invisible browser-only state unless there is a strong reason.
URL state is a product feature
Teams sometimes treat query strings and route state as implementation details. They are not. They are how users share, revisit, and reason about the app.
If a filtered list or detail view matters enough to render, it usually matters enough to have a stable URL.
That is also where progressive enhancement stays strong: the same route should make sense whether HTMX is active or not.
Partial navigation should respect browser behavior
When you use features like hx-push-url, treat them as part of the navigation contract, not as decoration.
Ask a few practical questions:
- If the user refreshes here, does the screen still make sense?
- If the user shares this URL, will another person land in the same place?
- If HTMX is unavailable, does a normal request still reach a useful page?
Those questions catch most navigation mistakes early.
Avoid hidden-screen architecture
The biggest navigation smell is when the real state of the screen exists only in a web of client-side assumptions. Once that happens, debugging and sharing links both get worse.
Server-driven UI works best when the browser URL, the server route, and the rendered HTML all tell the same story.