@@jjaimealeman That's not entirely true. Subsequent visitors have nothing to gain from what another visitor did. At most, only visitors from the same POP may get a cached version from that CDN POP. But that's not all visitors, nor is it guaranteed. With self hosting you have an unaltered version of the library. External hosting allows for hijacking of that dependency. It's also an external dependency, so if that server or DNS has issues, you now have issues. Lastly, HTTP2 can actually serve the serve the file faster since your browser has already established a TCP connection to your site.
Having a shared CDN gained popularity in the early 2000's. While there many libraries, JQuery was gaining dominance. The idea is that if MOST websites loaded JQuery, it would be more efficient to have a CDN referenced on every website. This way the browser could cache the file and re-use it across websites saving on bandwidth and hard disk space.
Self-hosting > CDN if there’s a way to do it with Astro. Don’t know much about Astro yet but I can imagine it has a /public or /static folder that can serve static content yes? The CDN being down the same day as a viral article about one of my sites is the kind of scenario that compels me to self host anything I can as a matter of course.
It seems very useful but why .astro tho? what if the user goes to that file path instead, isnt that just a public route? how can i protect that "endpoint"
What are the real prod use cases for HTMX? Seems like sprinkling into existing traditional server rendered sites / apps. Building a whole app with it seems awkward.
I'd say that with htmx AND alpinejs, the majority of frontend reactivity requirements can be met. The bundle size of htmx and alpinejs combined is still less than react-dom by about 20 MB. That said, I think there's really only one main reason not to use the serverless options: *backend savings*. Especially if you get up to 5 or 6 active projects, serverless costs can really get up there. It really just comes down to that for the more cost effective backend (using an actually fast, compiled language), htmx is generally more suited than the modern frameworks. The modern frameworks have kind of backed themselves in a corner where they really only work well/conveniently in a serverless environment. TL;DR: Use the modern frameworks for projects you need to scale effortlessly, but have a cheaper backup stack for smaller projects so you can host many of them without incurring too much costs.
Jack Herrington has a 9 mins long video on HTMX + Astro where he shows how to npm install and configure htmx in Astro
when people are saying back in the day I think they're talking about before 10 yrs ago.
I find it better to serve the JS file for HTMX myself from my server. But CDN is the way most people prefer to do it
The purpose of the CDN is so that subsequent visitors have HTMX cached, so it loads faster.
What benefit is there to self-hosting? 🤔
htmx.min.js.gz is 15675 bytes btw.
@@jjaimealeman That's not entirely true. Subsequent visitors have nothing to gain from what another visitor did. At most, only visitors from the same POP may get a cached version from that CDN POP. But that's not all visitors, nor is it guaranteed. With self hosting you have an unaltered version of the library. External hosting allows for hijacking of that dependency. It's also an external dependency, so if that server or DNS has issues, you now have issues. Lastly, HTTP2 can actually serve the serve the file faster since your browser has already established a TCP connection to your site.
Having a shared CDN gained popularity in the early 2000's. While there many libraries, JQuery was gaining dominance. The idea is that if MOST websites loaded JQuery, it would be more efficient to have a CDN referenced on every website. This way the browser could cache the file and re-use it across websites saving on bandwidth and hard disk space.
Self-hosting > CDN if there’s a way to do it with Astro. Don’t know much about Astro yet but I can imagine it has a /public or /static folder that can serve static content yes?
The CDN being down the same day as a viral article about one of my sites is the kind of scenario that compels me to self host anything I can as a matter of course.
I GOTTA check this out 🎉
The AH Stack?
With Islands isn't it now pointless to use HTMX with Astro?
I would not say so. HTMX provides a lot of sugar on top. But Islands are awesome 💙
thanks James, can you tell me about security to avoid other websites using your api on htmx and Astro?
I think usually just need to set up the CORS.
It seems very useful but why .astro tho? what if the user goes to that file path instead, isnt that just a public route? how can i protect that "endpoint"
What are the real prod use cases for HTMX? Seems like sprinkling into existing traditional server rendered sites / apps. Building a whole app with it seems awkward.
I'd say that with htmx AND alpinejs, the majority of frontend reactivity requirements can be met. The bundle size of htmx and alpinejs combined is still less than react-dom by about 20 MB. That said, I think there's really only one main reason not to use the serverless options: *backend savings*. Especially if you get up to 5 or 6 active projects, serverless costs can really get up there. It really just comes down to that for the more cost effective backend (using an actually fast, compiled language), htmx is generally more suited than the modern frameworks. The modern frameworks have kind of backed themselves in a corner where they really only work well/conveniently in a serverless environment.
TL;DR: Use the modern frameworks for projects you need to scale effortlessly, but have a cheaper backup stack for smaller projects so you can host many of them without incurring too much costs.
Last 🥲
First🎉