3 ms·

We have been using HTMX to create performant storefronts and the results are satisfactory. https://farmrio.deco.site/ https://farmrio.deco.site/ is one of the

by lucis 2y ago

We have been using HTMX to create performant storefronts and the results are satisfactory. https://farmrio.deco.site/ https://farmrio.deco.site/ is one of the largest clothing retailers in Brazil and all the frontend interactions use HTMX, alongside a partial rendering strategy we developed. More info at https://deco.cx/en/blog/htmx-first-class-support https://deco.cx/en/blog/htmx-first-class-support

lelandfe 2y ago
Love how good the CLS is. I wonder if you can deal with flashes of white during navigation with the new View Transitions API
- lelandfe 2y ago
  Oh, it's because the site does `*{visibility:hidden}` during loading. Don't do that, show us the intermediate state >:) You're artificially making your FCP also be your TTI, which means page navigation, when everything should be cached and fast, feels slow. That's not something e.g. Lighthouse tells you. I recommend showing the page right away, even if there's going to be jank. Jank/Cumulative layout shifts can be fixed later.
boredtofears 2y ago
I'm not sure this is htmx's fault but I wouldn't exactly describe that as snappy
- heavensteeth 2y ago
  I thought that too, but whole page loads are slow too; I assume it's just because I live nowhere near Brazil.
s6af7ygt 2y ago
The example on the blog post is one of those that makes me severely question HTMX and the stuff that we're doing. Doing HTTP requests to increase a counter, or affecting any local-only state change at all, seems so wild to me.
- karmarepellent 2y ago
  It makes me question what we are doing too. I'm using HTMX extensively at work, but I never use it to only update local state. A few lines of Javscript on the client will do that. However I think it's a powerful solution to updating the DOM when state changes on the backend and a roundtrip is required anyway. For that matter the examples on the official project site are better to understand proper use cases for HTMX [0]. Personally I use Active Search and Edit/Delete Row a lot. While Active Search does not change state in the backend, I found it's still a valid use case for HTMX when searching large data sets, since the backend is (in my case) just way faster to search through a large data set. It all comes down to your ability as a developer to find the proper solution to the problem at hand. A counter does not need HTMX. [0] https://htmx.org/examples/ https://htmx.org/examples/
- halfcat 2y ago
  “Counter app” is basically “hello world”, not how best practice is conveyed. If you’re using an HTTP request to update a counter, it would be to update the persistent server-side state of that counter (which you’d also do if you’re using React and a JSON API). No one is advocating for using HTMX for purely client-side state. They’ve been very consistent about this, recommending Alpine, vanilla JS, Stimulus, Vue, and so forth when you need pure client-side state.
- Tabular-Iceberg 2y ago
  What’s the use case for a counter that doesn’t update the backend? For example a like counter wouldn’t be much good if nobody else can see your like.

by lucis 2y ago

lelandfe 2y ago

Love how good the CLS is. I wonder if you can deal with flashes of white during navigation with the new View Transitions API

lelandfe 2y ago
Oh, it's because the site does `*{visibility:hidden}` during loading. Don't do that, show us the intermediate state >:) You're artificially making your FCP also be your TTI, which means page navigation, when everything should be cached and fast, feels slow. That's not something e.g. Lighthouse tells you. I recommend showing the page right away, even if there's going to be jank. Jank/Cumulative layout shifts can be fixed later.

boredtofears 2y ago

I'm not sure this is htmx's fault but I wouldn't exactly describe that as snappy

heavensteeth 2y ago
I thought that too, but whole page loads are slow too; I assume it's just because I live nowhere near Brazil.

s6af7ygt 2y ago

The example on the blog post is one of those that makes me severely question HTMX and the stuff that we're doing. Doing HTTP requests to increase a counter, or affecting any local-only state change at all, seems so wild to me.

karmarepellent 2y ago
It makes me question what we are doing too. I'm using HTMX extensively at work, but I never use it to only update local state. A few lines of Javscript on the client will do that. However I think it's a powerful solution to updating the DOM when state changes on the backend and a roundtrip is required anyway. For that matter the examples on the official project site are better to understand proper use cases for HTMX [0]. Personally I use Active Search and Edit/Delete Row a lot. While Active Search does not change state in the backend, I found it's still a valid use case for HTMX when searching large data sets, since the backend is (in my case) just way faster to search through a large data set. It all comes down to your ability as a developer to find the proper solution to the problem at hand. A counter does not need HTMX. [0] https://htmx.org/examples/ https://htmx.org/examples/
halfcat 2y ago
“Counter app” is basically “hello world”, not how best practice is conveyed. If you’re using an HTTP request to update a counter, it would be to update the persistent server-side state of that counter (which you’d also do if you’re using React and a JSON API). No one is advocating for using HTMX for purely client-side state. They’ve been very consistent about this, recommending Alpine, vanilla JS, Stimulus, Vue, and so forth when you need pure client-side state.
Tabular-Iceberg 2y ago
What’s the use case for a counter that doesn’t update the backend? For example a like counter wouldn’t be much good if nobody else can see your like.