@vintprox@syntaxseed oh i dont care about heresay - i couldn't tell if it was memey or an actual attempt at something from the documentation. because of a lot of things like those points where i was like "idk if thats so good."
but it also keeps coming up and im trying to be less discounting of everything all the time.
@bobmagicii@vintprox I think it has some good specific use cases. But there is definitely a risk of it being used in situations it's not appropriate for.
But if you have a hypermedia heavy output, or a lot of form-based CRUD screens... it looks like it can streamline things & get us away from constant full-page refreshes.
@vintprox@bobmagicii@syntaxseed Are you sure? My understanding of htmx,having just read some of its docs, is that it's still single request. It's not going to DDOS your server. Your php may regenerate more code than strictly necessary, but no more than it would sans htmx.
@vintprox Sure, but if you're loading new content from the server there's a second request when you click the button, period. Any language, htmx or raw JS or Angular, there's always a request there. Even with no JS at all, there's a second full page load at that point. So I don't know what you're complaining about. The HTTP count is identical in all cases.
@Crell@vintprox@bobmagicii@syntaxseed with proper caching headers, many of these requests should have minimum impact on the server. And for data heavy endpoints, well, you would be hitting anyway a JSON endpoint (or maybe more than one).
@vintprox@bobmagicii@syntaxseed Naively, you are correct. But in the real world there should be multiple intelligent layers of caching. Only content that needs to be regenerated should be. On the PHP side one ought to cache generation based as closely as possible on the data, and on the edge, through your CDN, based on time. Such that only 10% of your requests for dynamic content hits PHP, and only 10% of those requests (or fewer) full page gen.
Add comment