- Infinite scroll: HTMX detects the specified viewpoint and requests the next batch of content. The backend returns only the rendered partial HTML content that HTMX appends to the bottom of the page.
- Next page of a paginated content: if the users clicks on the 'Next page' button, the backend returns only the rendered HTML content of the next page, HTMX replaces only this part of the page.
- Form submission/validation: you can skip most of the frontend validation and use the backend for it. If the form has an error, HTMX replaces the new rendered form with the inlined error messages. Otherwise it can forward the user to the next page or shows some success message.
- Inline edit: e.g. click on the row in a table to load a small form just for that line. After the submission the backend returns the updated rendered table.
- Chained select input elements: when the user selects something in the first dropdown, it triggers an HTMX request that loads just the next select element that reflects the value of the first one.
- Background task with progress bar: just return a delayed, automatically triggered HTMX request from the backend until the task is finished. The status (e.g width) of the progress bar is also calculated on the backend.
- Search preview: with the builtin debounce filter trigger a search request that returns the search suggestions.
- Multiple small(er) updates on the page: one HTMX request can return multiple HTML partials that updates any part of the page. If you couple it with the builtin automated polling/websocket, you can build a live dashboard easily.
Of course you can do any of these with a SPA framework coupled to the backend API. But with HTMX you don't have to write a single line of JS, just put some htmx-something="..." attributes in the backend template files.
[0] and [1] are relevant sections of a much longer guide that go into more detail about the tradeoffs.
[0] https://www.saaspegasus.com/guides/modern-javascript-for-dja...
[1] https://www.saaspegasus.com/guides/modern-javascript-for-dja...
Vue positions itself for anything from jQuery replacement all the way to a full SPA and everything in between.
Anything works that way as long as it doesn't come with a built in router and you are careful not to accidentally bundle two different versions of your runtime.
The main advantage I see with this approach is you'll have only one set of models/actions in the server, instead of models in server + models in client. The logic won't be spread between client and server, which make for easier testing among other benefits. For larger apps, this is a significant win.