Been looking at this one. I inherited a project and I set it up to use puppeteer and chrome server side to generate a PDF from HTML but it's too much overhead. I want to do this all on the frontend because it should be simple enough to do and can use less resources on the server.
BTW, if you can help me: I've been struggling with WhatsApp Business API for some days to make my app receive webhooks. It receives the GET verification request but when I send a message to the number I never get the POST. Have you had this problem?
We have been using HTMX to create performant storefronts and the results are satisfactory.
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.
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.
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.
“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.
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.
It's a popular trend with e-commerce (our main field), which usually means not using the proprietary frontend framework that e-commerce platforms offer (Shopify, Magento...)
But deco itself it's not headless, it has all the body parts. You can use it as a headless CMS if you want to.
the fact that we're open-source makes it easy to create new integrations as well. you can take a look at https://github.com/deco-cx/apps to see how it works.
it's high priority for us to make this even easier and also to incentivize our community to create apps for most CMSes and APIs
Google has actually released Magenta [0] which is a plugin within Ableton that can do just that. It's pretty cool, it generates interesting melodic content at the click of a button.
