6 ms·

One thing I've been struggling with using HTMX... with an app and a frontend REST API I've found I can really kinda quickly craft a frontend by filtering down w

by rtpg 2y ago

One thing I've been struggling with using HTMX... with an app and a frontend REST API I've found I can really kinda quickly craft a frontend by filtering down whatever resources I need (though it's honestly pretty wasteful at times). With HTMX I'm finding myself needing to have as many backend views as I have ways of interacting with a page. I still have to write the frontend, and on top of that I gotta make a bunch of one-off backend views for many interactions. What am I doing wrong?

BeefySwain 2y ago
Check these out and see if they provide any insight for your specific issues :) - https://htmx.org/essays/template-fragments/ https://htmx.org/essays/template-fragments/ - https://htmx.org/essays/10-tips-for-ssr-hda-apps/ https://htmx.org/essays/10-tips-for-ssr-hda-apps/
djbusby 2y ago
I make htmx sites built around view fragments rather than pages. And when I need a page it's just a set of fragments. I make "API" endpoints fir the needed fragments and call via ssr on first paint, then as needed from the htmx side.
- hyperdang 2y ago
  [flagged]
  - esaym 2y ago
    rofl
- hyperdang 2y ago
  [flagged]
- librasteve 2y ago
  this is my medium term intent with HTMX & Raku ... I have in mind a programmatic / functional style of building websites where I can compose whole pages and sites
_heimdall 2y ago
I've tried HTMX with a few different back end frameworks and languages, my setup varies a lot based on which framework/language I use. The pattern I've been happiest with is when I can have a templating language designed to work really well with a component (or partials) approach. I break down the UI into smaller components as I add more HTMX interactions. The UI is effectively a tree of nested components, much like react or svelte. When an HTMX request is sent, the API handler logic runs and instead of returning a success response it sends back HTML for the individual component(s) that HTMX needs to update. tl;dr; When a request comes in, check headers to see if it was an HTMX request. If it wasn't, handle the API logic and return the full HTML page. If it was an HTMX request, still run the API logic but send back only the rendered components/partials that changed.
- rtpg 2y ago
  yeah it's just that when I have a REST API I get like... I guess 20 or so endpoints "for free" (since I can PATCH specific fields up in interesting ways). Maybe I need to be writing REST-looking form submission endpoints.... but then I have the immediate issue of presentation.
- brandenclark 2y ago
  This is exactly how I’ve been doing my recent projects and it just works so smoothly. > send back only the rendered components/partials that changed. What does this look like for you in practice? I’m imagining you have specific APIs per component/partial that mimic what happens during the full page load. Is there anything else you’re doing? Also, does “changed” just mean the resource was requested and you return a potentially refreshed partial? Or are you returning a signal to ignore triggering a page update when you can identify the rendered component has no difference?
halfcat 2y ago
When I build a page that uses HTMX, I go one of two ways. Traditionally I first build it as a fully server-side rendered page. Once that’s working I setup my views to return HTML partials for different parts of the page. So I might still have multiple views (or I might have single views that handle path parameters, query parameters, etc), but each is then basically just returning part of the existing template: Full page: return render(request, "jobs/index.html", ...) Some part of the page: return render(request, "jobs/index.html#status", ...) You can sort of think of this the same as you would with JSON API endpoints, where you still need different endpoints handling different HTTP methods (GET, POST, etc) for the different CRUD operations, and there’s a tradeoff regarding how granular you get with views, but typically you can make the views pretty generic and reusable (the same way you can make JSON API endpoints that essentially just serialize database query results). There’s an article [0] that gives an example of a similar approach. More recently I’ve been using a more component-based approach, using something like htpy [1] where I build up the page out of components (like you would in React), and sprinkle JS and CSS into the HTML with Alpine and Tailwind. [0] https://www.circumeo.io/blog/entry/django-htmx-and-template-partials/ https://www.circumeo.io/blog/entry/django-htmx-and-template-... [1] https://htpy.dev/ https://htpy.dev/
imacrayon 2y ago
Check out https://alpine-ajax.js.org https://alpine-ajax.js.org it defaults to using the same template views you would in a typical JavaScript-less app, then you can sprinkle in fragments where you need to optimize requests.
ysavir 2y ago
This is the thing that makes me lose interest in HTMX. People talk about it like it eliminates the need for JS/React/etc, but as far as I can tell, you're still writing those same templates, just using your backend language instead of JS. Which is convenient, but hardly "less code", just a different language, and that backend language probably lacks a lot of functionality you'd want for UI convenience. That's all fine if you'll never want those UI conveniences, by my experience has been that the want of those UI conveniences creep in over time, and eventually you regret not using something that makes them native and easy. I haven't actually played around with HTMX, so I might be sizing it up wrong, but it's mission statement just never resonated with me enough to want to try it out.
- emseetech 2y ago
  The value of HTMX is that state now resides solely on the server, and the browser becomes only a representation of that state. This simplifies applications considerably because maintaining two copies of the state between client and server is the source of a lot of complexity in modern applications. It wasn't about writing less code (although it is about writing less javascript) but about working with the concept of hypermedia instead of against or around it.
  - rtpg 2y ago
    Something I dislike about this argument is that there are a lot of UX flows where "tracking the state server-side" is a _major_ pain in the butt compared to having client-side state. And popular backend frameworks are not super up to the task! I have the impression that older web frameworks did in fact have a good amount of statefulness built in, and that causes a whole host of issues, so I believe to understand _why_ modern backend frameworks really don't lean into that.
    - emseetech 2y ago
      You're absolutely right, htmx is not built for every UX flow. But neither is React. And we've been reaching for it by default for everything and that's been a mistake. So much of what's built these days could be stateless MPAs. Servers have gotten crazy fast, and I'd certainly rather optimize for page size and server latency than build a React app. With the upcoming views transitions api, a bit of htmx, and custom web components and you get 95% of what React offers without anywhere near the package size or complexity. You don't even need a compile step. I'd never argue htmx is best for all use cases, I would hate for it to mutate the way React has, trying to be everything to everyone. But I hope htmx is the start of re-thinking how they approach the web and realizing that there are significantly simpler ways to build a frontend.
devjab 2y ago
HTMX pairs incredibly well with something like Go’s templates. Giving you the “what you’d want react to be” experience for many scenarios. I imagine it’s similar with other languages with good templating engines, I just know it’s extremely easy to build things with Go and HTMX. That being said, HTMX is not for everything. It’s great for internal tools as long as you don’t have very complex role-based access model. But security and access rights is where I think HTMX quickly becomes too complicated compared to a more traditional approach. As far as having “too many back end views” I do think that is down to you choosing an “incompatible” backend for your HTMX. It’s hard to say without knowing your details. You do say that you put a REST api behind it, but why would you do that with HTMX?
- librasteve 2y ago
  In the article I show HTMX and Pico CSS with Raku and Cro templates (Cro is one of the leading Raku web frameworks - there are others such as Hummingbird) in the same role as Go and ... (put your favourite Go HTML template engine here) - I am currently implementing the basic htmx.org examples in Raku by translating from https://github.com/Konfuzian/htmx-examples-with-flask/tree/main https://github.com/Konfuzian/htmx-examples-with-flask/tree/m... which has them in Python / Flask. The HMTX Discord has about 35 channels across all the various server side language options (including node). Certainly agree that HTMX is not for everything. Nor is Raku ;-)
chromanoid 2y ago
You may want to look at https://roca-style.org/ https://roca-style.org/ If you have problems filtering in the backend but it's easy in the frontend your backend technology is probably lacking.
stuckinhell 2y ago
yea I'm seeing alot of people combine it with alpine, but then whats the point ?

by rtpg 2y ago

BeefySwain 2y ago

Check these out and see if they provide any insight for your specific issues :) - https://htmx.org/essays/template-fragments/ https://htmx.org/essays/template-fragments/ - https://htmx.org/essays/10-tips-for-ssr-hda-apps/ https://htmx.org/essays/10-tips-for-ssr-hda-apps/

djbusby 2y ago

I make htmx sites built around view fragments rather than pages. And when I need a page it's just a set of fragments. I make "API" endpoints fir the needed fragments and call via ssr on first paint, then as needed from the htmx side.

hyperdang 2y ago
[flagged]
- esaym 2y ago
  rofl
hyperdang 2y ago
[flagged]
librasteve 2y ago
this is my medium term intent with HTMX & Raku ... I have in mind a programmatic / functional style of building websites where I can compose whole pages and sites

_heimdall 2y ago

I've tried HTMX with a few different back end frameworks and languages, my setup varies a lot based on which framework/language I use. The pattern I've been happiest with is when I can have a templating language designed to work really well with a component (or partials) approach. I break down the UI into smaller components as I add more HTMX interactions. The UI is effectively a tree of nested components, much like react or svelte. When an HTMX request is sent, the API handler logic runs and instead of returning a success response it sends back HTML for the individual component(s) that HTMX needs to update. tl;dr; When a request comes in, check headers to see if it was an HTMX request. If it wasn't, handle the API logic and return the full HTML page. If it was an HTMX request, still run the API logic but send back only the rendered components/partials that changed.

rtpg 2y ago
yeah it's just that when I have a REST API I get like... I guess 20 or so endpoints "for free" (since I can PATCH specific fields up in interesting ways). Maybe I need to be writing REST-looking form submission endpoints.... but then I have the immediate issue of presentation.
brandenclark 2y ago
This is exactly how I’ve been doing my recent projects and it just works so smoothly. > send back only the rendered components/partials that changed. What does this look like for you in practice? I’m imagining you have specific APIs per component/partial that mimic what happens during the full page load. Is there anything else you’re doing? Also, does “changed” just mean the resource was requested and you return a potentially refreshed partial? Or are you returning a signal to ignore triggering a page update when you can identify the rendered component has no difference?

halfcat 2y ago

When I build a page that uses HTMX, I go one of two ways. Traditionally I first build it as a fully server-side rendered page. Once that’s working I setup my views to return HTML partials for different parts of the page. So I might still have multiple views (or I might have single views that handle path parameters, query parameters, etc), but each is then basically just returning part of the existing template: Full page: return render(request, "jobs/index.html", ...) Some part of the page: return render(request, "jobs/index.html#status", ...) You can sort of think of this the same as you would with JSON API endpoints, where you still need different endpoints handling different HTTP methods (GET, POST, etc) for the different CRUD operations, and there’s a tradeoff regarding how granular you get with views, but typically you can make the views pretty generic and reusable (the same way you can make JSON API endpoints that essentially just serialize database query results). There’s an article [0] that gives an example of a similar approach. More recently I’ve been using a more component-based approach, using something like htpy [1] where I build up the page out of components (like you would in React), and sprinkle JS and CSS into the HTML with Alpine and Tailwind. [0] https://www.circumeo.io/blog/entry/django-htmx-and-template-partials/ https://www.circumeo.io/blog/entry/django-htmx-and-template-... [1] https://htpy.dev/ https://htpy.dev/

imacrayon 2y ago

Check out https://alpine-ajax.js.org https://alpine-ajax.js.org it defaults to using the same template views you would in a typical JavaScript-less app, then you can sprinkle in fragments where you need to optimize requests.

ysavir 2y ago

This is the thing that makes me lose interest in HTMX. People talk about it like it eliminates the need for JS/React/etc, but as far as I can tell, you're still writing those same templates, just using your backend language instead of JS. Which is convenient, but hardly "less code", just a different language, and that backend language probably lacks a lot of functionality you'd want for UI convenience. That's all fine if you'll never want those UI conveniences, by my experience has been that the want of those UI conveniences creep in over time, and eventually you regret not using something that makes them native and easy. I haven't actually played around with HTMX, so I might be sizing it up wrong, but it's mission statement just never resonated with me enough to want to try it out.

emseetech 2y ago
The value of HTMX is that state now resides solely on the server, and the browser becomes only a representation of that state. This simplifies applications considerably because maintaining two copies of the state between client and server is the source of a lot of complexity in modern applications. It wasn't about writing less code (although it is about writing less javascript) but about working with the concept of hypermedia instead of against or around it.
- rtpg 2y ago
  Something I dislike about this argument is that there are a lot of UX flows where "tracking the state server-side" is a _major_ pain in the butt compared to having client-side state. And popular backend frameworks are not super up to the task! I have the impression that older web frameworks did in fact have a good amount of statefulness built in, and that causes a whole host of issues, so I believe to understand _why_ modern backend frameworks really don't lean into that.
  - emseetech 2y ago
    You're absolutely right, htmx is not built for every UX flow. But neither is React. And we've been reaching for it by default for everything and that's been a mistake. So much of what's built these days could be stateless MPAs. Servers have gotten crazy fast, and I'd certainly rather optimize for page size and server latency than build a React app. With the upcoming views transitions api, a bit of htmx, and custom web components and you get 95% of what React offers without anywhere near the package size or complexity. You don't even need a compile step. I'd never argue htmx is best for all use cases, I would hate for it to mutate the way React has, trying to be everything to everyone. But I hope htmx is the start of re-thinking how they approach the web and realizing that there are significantly simpler ways to build a frontend.

devjab 2y ago

HTMX pairs incredibly well with something like Go’s templates. Giving you the “what you’d want react to be” experience for many scenarios. I imagine it’s similar with other languages with good templating engines, I just know it’s extremely easy to build things with Go and HTMX. That being said, HTMX is not for everything. It’s great for internal tools as long as you don’t have very complex role-based access model. But security and access rights is where I think HTMX quickly becomes too complicated compared to a more traditional approach. As far as having “too many back end views” I do think that is down to you choosing an “incompatible” backend for your HTMX. It’s hard to say without knowing your details. You do say that you put a REST api behind it, but why would you do that with HTMX?

librasteve 2y ago
In the article I show HTMX and Pico CSS with Raku and Cro templates (Cro is one of the leading Raku web frameworks - there are others such as Hummingbird) in the same role as Go and ... (put your favourite Go HTML template engine here) - I am currently implementing the basic htmx.org examples in Raku by translating from https://github.com/Konfuzian/htmx-examples-with-flask/tree/main https://github.com/Konfuzian/htmx-examples-with-flask/tree/m... which has them in Python / Flask. The HMTX Discord has about 35 channels across all the various server side language options (including node). Certainly agree that HTMX is not for everything. Nor is Raku ;-)

chromanoid 2y ago

You may want to look at https://roca-style.org/ https://roca-style.org/ If you have problems filtering in the backend but it's easy in the frontend your backend technology is probably lacking.

stuckinhell 2y ago

yea I'm seeing alot of people combine it with alpine, but then whats the point ?