Pleasantly surprised by your insight and delivery. Very articulate, and well thought out. I love finding new channels that are immediately valuable. Looking forward to watching this channel grow.
I personally really like the new Alpine Ajax plugin. Basically it extends alpine to include the HTMX functionality in a more integrated way, and adding only 3 kB to the bundle size instead of 13 kB if you had alpine either way
For high-speed rendering, htmx has a websockets extension you can use, so you're not making a brand new connection for every request. It may not be suitable for every use-case, but definitely something to look at if you're using htmx and you need much faster client/server interaction.
Currently I'm using and combining HTMX with Alpine JS. It's so cool and easy to implement. Your insight convinced me that I'm not using the wrong combination. Haha!
This is exactly what i needed !! You helped me to determine my future for at least next 2 years... PHP LARAVEL HTMX ALPINE , I'll hang out with these nice guys
Yeah looks like you can use the element's `open` attribute to open and close which is cool - like that we're doing more Hypermedia based controls! Interestingly MDN recommends using the JS functions to handle this rather than the attribute. No explanation why though - developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog
@@HAMYLABS I think the `open` attribute opens it as a dialog, not a modal. I think that is the same as the `show()` javascript method. The `showModal()` opens it as a modal. The modal blocks everything else on the page if open.
This was great. (Far better than ChatGPT's answer.) You super clearly identified how they are complementary (note spelling disagreement with your blog post). There are lots of RUclips that plunge into using both, but they don't provide a clear overview of (a) why use both? and (b) use which for what functionality? So count me as a new subscriber!
TY for the kind words and glad you found it helpful! Oh no I realized I often spell complementary as complimentary -> I thought they were spelled the same =D
I love this and learnt a lot. Welldone. Though the two things I think are debatable and I don't really agree on are: 1. Having a JS Framework doesn't lock you in to use technologies like NodeJS like on the backend. I build apps with these frameworks with frameworks like laravel and django also. 2. No one is talk about some of the limitations of HTMX like scaling and needing to have server control. What happens when I need to integrate a 3rd party API and working with a team? JS Frameworks do these things better... 3. Correct me if I'm wrong but HTML responses tend to be larger than JSON's I currently use AplineJS and HTMX in some projects but I still think it's worth really stating in videos such as this so we don't preach a convention or way of building web apps that is better then later down the line, start with "Ummm, Ok so that might not be the best way anymore..." Isn't that the case with rendering on the client vs rendering on the server, JS frameworks and so many other examples I can give....
Glad you found it useful and thanks for the details responses! > Stating in videos that this isn't the only way to build things Totally agree that there is no right way to do things - just a bunch of tradeoffs. The problem is if I said this in every video then it's basically just fluff - I've wasted 2 mins of people's time instead of just focusing on the thing I am presenting today. So this is also a tradeoff - I choose to try and make my videos focused on the technology at hand and assume that my viewers know that I am just a dumb guy on the internet and you need to make up your own mind ab this. > 1: JS Framework doesn't lock you into NodeJS on the backend So I agree that you can choose whatever you want on the backend and still use JS framework on the frontend. But usually the JS framework does involve NodeJS at some point. Q1: How are you using your JS framework of choice with Laravel / Django? In particular, what is compiling your JS framework of choice into usable HTML / CSS? In most cases I've seen this either as a separate frontend NodeJS monolith or many backend frameworks abstract this so they deal with the NodeJS integration themselves. But I don't use these much anymore so maybe I'm wrong. > 2: No one is talk about some of the limitations of HTMX like scaling and needing to have server control Q2: Why do you think HTMX reduces server control? I would think HTMX provides more server control than SPAs because everything is rendered on the server but curious to hear why you think it has less server control. RE: scaling - HTMX is MPA but with lighter reloads. MPAs have worked great for decades so this will scale better than an MPA at least perf wise. Maintainability wise is still to be seen. RE: 3rd party API - you would integrate the same way you do w JS. JS integrates w APIs via web requests. Your backend can do this too. > 3: HTML Responses are larger than JSON Sometimes. As always all approaches have tradeoffs. Both of these have ways that they are inefficient: * HTML - inefficient if sending lots of markup overhead (like tailwind styles tend to be hard to compress) * JSON - inefficient if you are overfetching / need to hit multiple APIs for a given page (like when you don't have a very flexible backend API surface) In both cases there are ways to mitigate. HTMX creator did a comparison of sizes and when both response types are compressed they are basically the same size - github.com/1cg/html-json-size-comparison But again there are ways to get both wrong and thus use inefficiently. I think time will tell if this is a widespread problem in production or not.
@@HAMYLABS I have a design pattern that I need help with. I have an ecommerce site and when a user adds to cart, the cart total badge in the top nav gets updates with an Html partial. However, when a user navigates back/history.push() they see the old cart total taken from cache. How do I retain the latest state even on history.push()? P.s anything on caching would be appreciated
HTMX functionalities are incredibly useful and feel almost irreplaceable (except if you wanna deal with AJAX yourself) while AlpineJS is more like a modern jquery that's only useful for those who have a hard time using js to do basic manipulation of the elements in the DOM.
Yeah I've been thinking ab playing around with the many alternatives out there to see how they work / tradeoffs: * datastar * alpine ajax * htmz * unpoly Probably more out there now too. Just haven't felt stuck / constrained w HTMX yet so haven't felt strong need but might get to it this summer
60fps iin the browser s not a problem for server side rendering if you use Phoenix and LiveView :) LiveView is a lot faster than HTMX since it uses websockets to transmit a tiny diff values between the server and the browser.
Interesting - do you have examples where they're doing that in a game or similar? I've seen demos where 60fps if possible but never a project that actually uses it so curious if you have one.
@@HAMYLABS high-performance games require a lot of CPU power, so they need C++, not Elixir. Phoenix shines and is great for real-time, fault-tolerant websites, which are its target, and its LiveView is obviously faster than HTMX. However, it is bound to Elixir and BEAM, while HTMX can work with any server-side technology. There is no silver bullet.
i've seen games build with liveview (same kind of thing like htmx), and it was fast.... (so the argument of not using htmx, when "when your app doesn't need complex, high speed rendering" is not necessarily true)
No course yet but been thinking about making some videos about them. Q: Anything you're stuck on / would like to learn about for building with HTMX and Alpine?
Besides Petite Vue being a dead project, it's more skewed towards using JS, not avoiding using JS, but still, you can do most of the things almost the same way as in Alpine. It is lighter, but has less QOL things like built-in transitions, and there are like 0 plugins for it, since it never gained traction. What Alpine is missing, are reusable UI components (you can just reuse logic, but no templates), but due to the nature of using those libs usually with some backend framework that can handle the component for you, it's not that big of a deal.
i disagree. alpine works better than htmx even if you do need to pull or push data, to or from the server. handling network error or http errors from html attributes is a nightmare. meanwhile, alpine is basically JS in html attributes. it uses `eval` under the hood. alpine make sense when you want to make something small and simple with little bit of reactivity.
Pleasantly surprised by your insight and delivery. Very articulate, and well thought out. I love finding new channels that are immediately valuable. Looking forward to watching this channel grow.
Thank you for watching and glad you found it valuable!
came across this vid and was pleasantly surprised, thanks for the clear explanation. I like your minimal basic approach i'm an advocate of that too...
This deserves more views. Very helpful overview. Web dev doesn’t have to be so complicated!!
I personally really like the new Alpine Ajax plugin. Basically it extends alpine to include the HTMX functionality in a more integrated way, and adding only 3 kB to the bundle size instead of 13 kB if you had alpine either way
Yeah just saw this earlier today - looks very clean and quite a bit simpler.
Might try it out in a future project
For high-speed rendering, htmx has a websockets extension you can use, so you're not making a brand new connection for every request. It may not be suitable for every use-case, but definitely something to look at if you're using htmx and you need much faster client/server interaction.
Currently I'm using and combining HTMX with Alpine JS. It's so cool and easy to implement. Your insight convinced me that I'm not using the wrong combination. Haha!
Awesome! Yeah I've found it to be a pretty simple and refreshing combo!
This is exactly what i needed !! You helped me to determine my future for at least next 2 years... PHP LARAVEL HTMX ALPINE , I'll hang out with these nice guys
If you use Laravel, just add Livewire. It uses Alpine. You really don't need HTMX.
A true demonstration of deep knowledge on a topic is if you can explain it simply. Thank you. (Edit: Prime should do a reaction video!)
Alpine AJAX is a very beautiful extension for Alpine that removes the need for using HTMX whatsoever for me personally.
Yep - they both provide similar things, partial reloads controlled by server.
its limited to forms. i like the flexibility of htmx.
for me, its htmx + alpinejs!
I think I just watched Dan Levy talk to me about HTMX & AlpineJS here. Excellent!
Showing a modal is easy with the new html tag. So you don't really need to much JavaScript for that
Yeah looks like you can use the element's `open` attribute to open and close which is cool - like that we're doing more Hypermedia based controls!
Interestingly MDN recommends using the JS functions to handle this rather than the attribute. No explanation why though - developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog
@@HAMYLABS I think the `open` attribute opens it as a dialog, not a modal. I think that is the same as the `show()` javascript method. The `showModal()` opens it as a modal. The modal blocks everything else on the page if open.
This was great. (Far better than ChatGPT's answer.) You super clearly identified how they are complementary (note spelling disagreement with your blog post). There are lots of RUclips that plunge into using both, but they don't provide a clear overview of (a) why use both? and (b) use which for what functionality? So count me as a new subscriber!
TY for the kind words and glad you found it helpful!
Oh no I realized I often spell complementary as complimentary -> I thought they were spelled the same =D
I was really confused about HTMX but it finally clicked. It actually seems super nice and simple after all. Great video. ++
Glad it helped!
Really good explanation, just what I wanted.
I love this and learnt a lot. Welldone.
Though the two things I think are debatable and I don't really agree on are:
1. Having a JS Framework doesn't lock you in to use technologies like NodeJS like on the backend. I build apps with these frameworks with frameworks like laravel and django also.
2. No one is talk about some of the limitations of HTMX like scaling and needing to have server control. What happens when I need to integrate a 3rd party API and working with a team? JS Frameworks do these things better...
3. Correct me if I'm wrong but HTML responses tend to be larger than JSON's
I currently use AplineJS and HTMX in some projects but I still think it's worth really stating in videos such as this so we don't preach a convention or way of building web apps that is better then later down the line, start with "Ummm, Ok so that might not be the best way anymore..."
Isn't that the case with rendering on the client vs rendering on the server, JS frameworks and so many other examples I can give....
Glad you found it useful and thanks for the details responses!
> Stating in videos that this isn't the only way to build things
Totally agree that there is no right way to do things - just a bunch of tradeoffs. The problem is if I said this in every video then it's basically just fluff - I've wasted 2 mins of people's time instead of just focusing on the thing I am presenting today.
So this is also a tradeoff - I choose to try and make my videos focused on the technology at hand and assume that my viewers know that I am just a dumb guy on the internet and you need to make up your own mind ab this.
> 1: JS Framework doesn't lock you into NodeJS on the backend
So I agree that you can choose whatever you want on the backend and still use JS framework on the frontend. But usually the JS framework does involve NodeJS at some point.
Q1: How are you using your JS framework of choice with Laravel / Django? In particular, what is compiling your JS framework of choice into usable HTML / CSS?
In most cases I've seen this either as a separate frontend NodeJS monolith or many backend frameworks abstract this so they deal with the NodeJS integration themselves. But I don't use these much anymore so maybe I'm wrong.
> 2: No one is talk about some of the limitations of HTMX like scaling and needing to have server control
Q2: Why do you think HTMX reduces server control?
I would think HTMX provides more server control than SPAs because everything is rendered on the server but curious to hear why you think it has less server control.
RE: scaling - HTMX is MPA but with lighter reloads. MPAs have worked great for decades so this will scale better than an MPA at least perf wise. Maintainability wise is still to be seen.
RE: 3rd party API - you would integrate the same way you do w JS. JS integrates w APIs via web requests. Your backend can do this too.
> 3: HTML Responses are larger than JSON
Sometimes. As always all approaches have tradeoffs. Both of these have ways that they are inefficient:
* HTML - inefficient if sending lots of markup overhead (like tailwind styles tend to be hard to compress)
* JSON - inefficient if you are overfetching / need to hit multiple APIs for a given page (like when you don't have a very flexible backend API surface)
In both cases there are ways to mitigate.
HTMX creator did a comparison of sizes and when both response types are compressed they are basically the same size - github.com/1cg/html-json-size-comparison
But again there are ways to get both wrong and thus use inefficiently. I think time will tell if this is a widespread problem in production or not.
I use both. I'd appreciate more vids on passing info/data between Alpine and HTMX.
Ooh that's a good idea! I'll add to my list
@@HAMYLABS I have a design pattern that I need help with. I have an ecommerce site and when a user adds to cart, the cart total badge in the top nav gets updates with an Html partial. However, when a user navigates back/history.push() they see the old cart total taken from cache. How do I retain the latest state even on history.push()?
P.s anything on caching would be appreciated
Great video, thank you very much for your insight!
HTMX functionalities are incredibly useful and feel almost irreplaceable (except if you wanna deal with AJAX yourself) while AlpineJS is more like a modern jquery that's only useful for those who have a hard time using js to do basic manipulation of the elements in the DOM.
Cool! Thank you, man!
Subscribed. Like your vibe, like your content.
Id love to hear your thoughts on data-star. The creator in a way combined Alpine and HTMX in a really clean way
Yeah I've been thinking ab playing around with the many alternatives out there to see how they work / tradeoffs:
* datastar
* alpine ajax
* htmz
* unpoly
Probably more out there now too. Just haven't felt stuck / constrained w HTMX yet so haven't felt strong need but might get to it this summer
Thanks, it was insightful
You can just EHTML, which is awesome for static content like SVG, HTML, Markdown and also can work with dynamic JSON responses.
Great insights!
Well, there is an ajax plugin for Alpine that looks quite sophisticated.
Looks pretty cool - alpine-ajax.js.org/
Seems like a slimmed down version of HTMX by design. Could definitely see this being a good way to go
My favorite combo is HTMX and HyperScript.
I hear it plays nicely together!
60fps iin the browser s not a problem for server side rendering if you use Phoenix and LiveView :) LiveView is a lot faster than HTMX since it uses websockets to transmit a tiny diff values between the server and the browser.
Interesting - do you have examples where they're doing that in a game or similar?
I've seen demos where 60fps if possible but never a project that actually uses it so curious if you have one.
@@HAMYLABS high-performance games require a lot of CPU power, so they need C++, not Elixir. Phoenix shines and is great for real-time, fault-tolerant websites, which are its target, and its LiveView is obviously faster than HTMX. However, it is bound to Elixir and BEAM, while HTMX can work with any server-side technology. There is no silver bullet.
i've seen games build with liveview (same kind of thing like htmx), and it was fast.... (so the argument of not using htmx, when "when your app doesn't need complex, high speed rendering" is not necessarily true)
it's fine as long as internet is stable
Can you do tutorial Rust + HTMX + AlpineJS
I don't do much Rust myself but might play w it in future.
Q: Is there something specific you're curious ab building w Alpine + HTMX?
It should be mentioned that the HOWL Stack acronym is the brain child of Carson Gross.
Yep - his essay is very good.
HOWL (Hypermedia on Whatever You Like) - htmx.org/essays/hypermedia-on-whatever-youd-like/
do you have a course for alpine and htmx together?
No course yet but been thinking about making some videos about them.
Q: Anything you're stuck on / would like to learn about for building with HTMX and Alpine?
wow rhis is epix
How does Alpine compare to Petite Vue?
Besides Petite Vue being a dead project, it's more skewed towards using JS, not avoiding using JS, but still, you can do most of the things almost the same way as in Alpine.
It is lighter, but has less QOL things like built-in transitions, and there are like 0 plugins for it, since it never gained traction.
What Alpine is missing, are reusable UI components (you can just reuse logic, but no templates), but due to the nature of using those libs usually with some backend framework that can handle the component for you, it's not that big of a deal.
can i use both?
Yes!
They are not complimentary if you use Alpine-ajax (you don't need HTMX).
Alpine-ajax is cool, but not as capable as htmx. htmx has way more features.
Both, 2EZ
Make a video on lit.js vs alpine.js
none of both?
There is no "Vs." Alpine complements HTMX
Yes - that is the point of this video =)
@@HAMYLABS then don't use "vs" in the title, subscribed ;-)
htmx is good until you hit interactivity problem Muahaha let's go SvelteKit!
That’s what you get by adding the use of Alpine.
What?
Why not both?
😮
i disagree. alpine works better than htmx even if you do need to pull or push data, to or from the server.
handling network error or http errors from html attributes is a nightmare. meanwhile, alpine is basically JS in html attributes. it uses `eval` under the hood.
alpine make sense when you want to make something small and simple with little bit of reactivity.