3 ms·

I can't work out what problem this solves. Personally, I'm not a fan of SPAs, but there's still a middle ground between that and a more traditional full-page re

I can't work out what problem this solves. Personally, I'm not a fan of SPAs, but there's still a middle ground between that and a more traditional full-page reload, server-side rendered approach. React, Elm, etc, should all allow for smaller parts of a page to be dynamic while the rest remains static.

sixhobbits 5y ago
They do, but they have a steeper learning curve and cause more separation between back and front end. Sometimes that's good, sometimes it isn't. [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-django-developers/htmx-alpine/ https://www.saaspegasus.com/guides/modern-javascript-for-dja... [1] https://www.saaspegasus.com/guides/modern-javascript-for-django-developers/client-server-architectures/ https://www.saaspegasus.com/guides/modern-javascript-for-dja...
- pythonaut_16 5y ago
  This is also one of the use cases that Vue targeted specifically and it greatly accelerated its adoption. Vue positions itself for anything from jQuery replacement all the way to a full SPA and everything in between.
  - zdragnar 5y ago
    It's how Facebook originally (still?) used react. 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.
Dauros 5y ago
HTMX helps you create an SPA-like experience without using a full SPA framework. You can utilize the full power of your favourite backend framework (e.g form validation, template-system, authorization, etc.) without writing JS code directly. Some examples: - 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.
felipeccastro 5y ago
HTMX is a middle ground - using it involves not having "full-page reloads" like traditional server rendered apps, but still having the productivity of server only apps. 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.

sixhobbits 5y ago

They do, but they have a steeper learning curve and cause more separation between back and front end. Sometimes that's good, sometimes it isn't. [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-django-developers/htmx-alpine/ https://www.saaspegasus.com/guides/modern-javascript-for-dja... [1] https://www.saaspegasus.com/guides/modern-javascript-for-django-developers/client-server-architectures/ https://www.saaspegasus.com/guides/modern-javascript-for-dja...

pythonaut_16 5y ago
This is also one of the use cases that Vue targeted specifically and it greatly accelerated its adoption. Vue positions itself for anything from jQuery replacement all the way to a full SPA and everything in between.
- zdragnar 5y ago
  It's how Facebook originally (still?) used react. 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.

Dauros 5y ago

HTMX helps you create an SPA-like experience without using a full SPA framework. You can utilize the full power of your favourite backend framework (e.g form validation, template-system, authorization, etc.) without writing JS code directly. Some examples: - 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.

felipeccastro 5y ago

HTMX is a middle ground - using it involves not having "full-page reloads" like traditional server rendered apps, but still having the productivity of server only apps. 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.