I use HTMX with a golang backend and Alpine if I need interactivity. As a result compared to previous versions of my applications with Nuxt or Astro, it's lighter, faster and much more robust. Also I'm more productive as a backend developer as I don't have to bother with the whole js/react/[insert framework] ecosystem.
Was gonna create a project with Nest on the backend and Next on the frontend, so you would recommend Htmx and Alpine instead of Next Js on the frontend?
@lardosian tbh, context really matters. Do you already know js/ts, maybe even js web frameworks? What kind of app is it? Is it ui heavy, think animations? Another plus for js is that the ecosystem is huge and it can save you a lot of time. But you have to choose wisely. I think a great usecase of htmx is when you dont no javascript and have no intention to learn / your team. Your app is just a basic crud or requires all the state to be on the server anyway. As js dev who actually likes to hope frameworks just to make coding more fun for myself i tried golang htmx aswell, but the dx was worse then solidstart and sveltekit.
@@luka1790 Thanks, I have experience building a fairly big React app which I enjoyed, this one is a small side project so maybe I should stick to what I know for the moment.
I like using HTMX, but for the React problem you mentioned of having different separate parts of the UI that need to be updated. Why not just use a state manager like Zustand which is around 1.2 kb compressed or Redux. I feel like the main advantage here of using HTMX is that the architecture of the server was already SSR and thus implementing HTMX wouldn't require much migration of the current services and it would save time. SSR is easily handled by React frameworks like NextJS or Remix but, for this case I see how it would have been overkill, double the time of work for an already working backend.
@@KodapsAcademy Yeh, I was understanding your video that way. i.e. Htmx being a good solution this case, because it's an update to an existing architecture - that's the idea here if I'm correct? ...great video by the way - I like this format/style. Nicely put together ;o,
Great talk. Except I don't need React at all since WebComponent are not that bad that some people say and vanilla JavaScript is not just a step in the process to learn React.
What if one use alpine js along with htmx to solve that transient ui state issue? Wouldn’t it be easier as the alpine js and htmx has the simillar philosophy and coding style?
I want to learn HTMX. Regarding React. Updating all the components would be simple with Redux. As soon as you get the response. You could update the "cart count" and "cart list".
That's a perfect use-case for HTMX. But I guess sticking with jQuery (and replacing the old jQuery plugin with an alternative or with custom code) would have done the job equally well. There are some things that I don't like about HTMX: Being basically just written as custom HTML attributes makes editor support tricky which might be problematic with refactoring and cause bugs in the long run. I'm also not sure if there's a good testing strategy for HTMX apart from E2E tests. Also you can't use TypeScript with it. On the other hand, you don't have a build step, so it's a far leaner dev workflow. It just won't scale up very well. That's why you also have React. Did you often run into situation where HTMX (or previously jQuery) pieces became too complex so you had to completely reimplement them in React? I wonder what would be a good tech stack that scales from your HTMX use-case up to your React use-case. Maybe Astro with something like SolidJS for its interactive islands?
@@yume6643 No TypeScript because with HTMX there's no build step. You add the HTMX library to your HTML and then you add your HTMX attributes to the HTML. And this means you also don't have separated pieces of frontend logic that you could unit-test. So afaik you can only have E2E and integration tests. But tbh I haven't really worked with HTMX yet, it's just what comes to my mind when I look at it.
Astro with SolidJS sounds like a very neat option. I'm learning SolidStart now, because I do like the way they don't bloatware everything, keep things as needed and it's also very performant. I'm a C++ Programmer, so Front-end stuff was never really my thing, I'm just learning a bit of it to create a portfolio/blog webapp. The first thing I realised was: there are sooooo many frameworks to choose from. How do you folks decide what to pick?
@@theintjengineer SolidStart is definitely really promising, especially now with the just released stable version 1.0! Deciding is really not easy. Usually companies already have settled on a stack. In this case, it takes a lot of experience and observation to establish a change. I usually discuss with other teammates when I observe problems like bad performance, misuse or repeating bad patterns that lead to hard to maintain code. Then we look different options, considering their popularity and stability, the experience of our teams, how hard or easy it would be to migrate etc. For personal fun projects, I just go with gut feeling.
@@VeitLehmann htmx has nothing to do with the issue you mentioned. It's just a way to make easier ajax call. Don't bother you with that...I mean, it's the html partial view that you have to test or your api endpoints. This what makes htmx a good try. We used to frontend logic separated because of fronted framework...without that, many concepts become a little bit...useless !
I work on a react / nextjs / redux / redux saga bloat stack for my work. since I came into the project after it shipped, I feel like I don't understand how the whole system works and I feel powerless to make any substantial changes. A couple weeks ago I started learning htmx and I built a project with near feature parity to what we have at work in just 5 days (only after work and on my own time too).
As it is currently set up, you need to create an account to go through checkout but not to add to your cart. If the user is not logged in we won't be able to send an abandoned cart email though
🌟 Wow, this video was incredibly insightful! Thank you so much for breaking down the pros and cons of HTMX vs React in such a clear and practical way. 🚀💻 💬 I have a question: Do you have plans to make more videos comparing different web technologies for specific use cases? It would be awesome to see more in-depth analyses like this! 📊🤔 Keep up the great work! Can't wait to see more content from you! 🎥👍
This means you're managing the dropdown's state through hypermedia, which implies using the network for every state update. The big advantage of pure frontend solutions such as a CSS lib like boostrap or tailwind, or a JS lib like AlpineJS, is that it happens only on the client, which is more performant and powerful. Performance : relying on the network is more costly that relying on client-side operations. Power : on top of that, Hypermedia As The Engine Of Application State (HATEOAS) is quite limited in terms of interactivity on the client. You can easily have an open/closed state, but as soon as you need something a bit more fancy, such as more complex states, animations or transitions, it falls short, as every small update relies on an external API. HATEOAS is great when you need a standardized way to interact with dynamic data structures on a server. For example, it's great for a public API.
So now you use both react and htmx? Isn't that a very unnecessary bloat you claimed to try to avoid? I seriously don't understand your problem with updating these three unconected components when adding something to cart. React is 100% perfectly suited for this job. Just learn how to use context API in instead of throwing in another technology. Seriously react is like the #1 solution for stuff like this and you gave that as a reason to lean for another technology..
No you've misunderstood what I was saying. We don't use React on the page (we use it elsewhere, in the customer area), only HTMX. The rest of the page is rendered statically using PHP / Twig, not React. And React can't encompass those components that don't share a (HTML) parent unless we go via useRef. which would end up being an unnecessary complication. In any case, React was most certainly not the right tool for this use case. I get your point that it would have been in a NextJS context, but it isn't here.
@@KodapsAcademy "React can't encompass those components that don't share a (HTML) parent unless we go via useRef" The lengths frontend devs will go to to avoid using an event bus is remarkable.
I use HTMX with a golang backend and Alpine if I need interactivity.
As a result compared to previous versions of my applications with Nuxt or Astro, it's lighter, faster and much more robust.
Also I'm more productive as a backend developer as I don't have to bother with the whole js/react/[insert framework] ecosystem.
Was gonna create a project with Nest on the backend and Next on the frontend, so you would recommend Htmx and Alpine instead of Next Js on the frontend?
@@lardosian oooohh yes !!!
@lardosian tbh, context really matters. Do you already know js/ts, maybe even js web frameworks?
What kind of app is it? Is it ui heavy, think animations? Another plus for js is that the ecosystem is huge and it can save you a lot of time. But you have to choose wisely.
I think a great usecase of htmx is when you dont no javascript and have no intention to learn / your team. Your app is just a basic crud or requires all the state to be on the server anyway.
As js dev who actually likes to hope frameworks just to make coding more fun for myself i tried golang htmx aswell, but the dx was worse then solidstart and sveltekit.
@@luka1790 Thanks, I have experience building a fairly big React app which I enjoyed, this one is a small side project so maybe I should stick to what I know for the moment.
@@lardosian no. instead use livewire
I like using HTMX, but for the React problem you mentioned of having different separate parts of the UI that need to be updated. Why not just use a state manager like Zustand which is around 1.2 kb compressed or Redux.
I feel like the main advantage here of using HTMX is that the architecture of the server was already SSR and thus implementing HTMX wouldn't require much migration of the current services and it would save time. SSR is easily handled by React frameworks like NextJS or Remix but, for this case I see how it would have been overkill, double the time of work for an already working backend.
Yeah if the backend was using Next we would clearly not have bothered with HTMX :D
@@KodapsAcademy
Yeh, I was understanding your video that way.
i.e. Htmx being a good solution this case, because it's an update to an existing architecture - that's the idea here if I'm correct?
...great video by the way - I like this format/style.
Nicely put together ;o,
Great talk.
Except I don't need React at all since WebComponent are not that bad that some people say and vanilla JavaScript is not just a step in the process to learn React.
What if one use alpine js along with htmx to solve that transient ui state issue? Wouldn’t it be easier as the alpine js and htmx has the simillar philosophy and coding style?
The transient state (e.g. if the dropdown is open or not) is simply managed by Bootstrap in our case :)
Alpine JS + Hotwired Turbo
I Am enjoying the HTMX, Alpine,Astro, tailwind stack with nestJS for all sensitive rest api stuff.
Hotwired Turbo plus AlpineJS have brilliant balance.
This is a better use case for web components.
I want to learn HTMX.
Regarding React.
Updating all the components would be simple with Redux.
As soon as you get the response. You could update the "cart count" and "cart list".
Yeah we needed to have the cart’s state to be controlled by the backend so Redux would be overkill here
Why not use Alpine for the small bits that needs interaction?
That's a perfect use-case for HTMX. But I guess sticking with jQuery (and replacing the old jQuery plugin with an alternative or with custom code) would have done the job equally well. There are some things that I don't like about HTMX: Being basically just written as custom HTML attributes makes editor support tricky which might be problematic with refactoring and cause bugs in the long run. I'm also not sure if there's a good testing strategy for HTMX apart from E2E tests. Also you can't use TypeScript with it. On the other hand, you don't have a build step, so it's a far leaner dev workflow. It just won't scale up very well. That's why you also have React.
Did you often run into situation where HTMX (or previously jQuery) pieces became too complex so you had to completely reimplement them in React?
I wonder what would be a good tech stack that scales from your HTMX use-case up to your React use-case. Maybe Astro with something like SolidJS for its interactive islands?
Why can't you use typescript????? Also why wouldn't you be able to test it?
I'm pretty sure it's going to scale much more efficiently than react.
@@yume6643 No TypeScript because with HTMX there's no build step. You add the HTMX library to your HTML and then you add your HTMX attributes to the HTML. And this means you also don't have separated pieces of frontend logic that you could unit-test. So afaik you can only have E2E and integration tests. But tbh I haven't really worked with HTMX yet, it's just what comes to my mind when I look at it.
Astro with SolidJS sounds like a very neat option. I'm learning SolidStart now, because I do like the way they don't bloatware everything, keep things as needed and it's also very performant.
I'm a C++ Programmer, so Front-end stuff was never really my thing, I'm just learning a bit of it to create a portfolio/blog webapp.
The first thing I realised was: there are sooooo many frameworks to choose from.
How do you folks decide what to pick?
@@theintjengineer SolidStart is definitely really promising, especially now with the just released stable version 1.0! Deciding is really not easy. Usually companies already have settled on a stack. In this case, it takes a lot of experience and observation to establish a change. I usually discuss with other teammates when I observe problems like bad performance, misuse or repeating bad patterns that lead to hard to maintain code. Then we look different options, considering their popularity and stability, the experience of our teams, how hard or easy it would be to migrate etc.
For personal fun projects, I just go with gut feeling.
@@VeitLehmann htmx has nothing to do with the issue you mentioned. It's just a way to make easier ajax call. Don't bother you with that...I mean, it's the html partial view that you have to test or your api endpoints. This what makes htmx a good try. We used to frontend logic separated because of fronted framework...without that, many concepts become a little bit...useless !
I work on a react / nextjs / redux / redux saga bloat stack for my work. since I came into the project after it shipped, I feel like I don't understand how the whole system works and I feel powerless to make any substantial changes. A couple weeks ago I started learning htmx and I built a project with near feature parity to what we have at work in just 5 days (only after work and on my own time too).
One minus is that you cannot fill your basket without creating an account and logging in. I wonder if this costs you some sales.
As it is currently set up, you need to create an account to go through checkout but not to add to your cart. If the user is not logged in we won't be able to send an abandoned cart email though
I think HTMX is a very elegant solution, but I use Livewire for Laravel in conjunction with Alpine JS. Is there an equivalent to Livewire for Symfony?
Symfony has bundles that integrate directly with Turbo (search for « Symfony UX »)
Greate example!
Thanks :)
Great explanation
🌟 Wow, this video was incredibly insightful! Thank you so much for breaking down the pros and cons of HTMX vs React in such a clear and practical way. 🚀💻
💬 I have a question: Do you have plans to make more videos comparing different web technologies for specific use cases? It would be awesome to see more in-depth analyses like this! 📊🤔
Keep up the great work! Can't wait to see more content from you! 🎥👍
htmx is just a simple edition of jQuery!
Well am using htmx for dropdown cart as well... why not?
This means you're managing the dropdown's state through hypermedia, which implies using the network for every state update.
The big advantage of pure frontend solutions such as a CSS lib like boostrap or tailwind, or a JS lib like AlpineJS, is that it happens only on the client, which is more performant and powerful.
Performance : relying on the network is more costly that relying on client-side operations.
Power : on top of that, Hypermedia As The Engine Of Application State (HATEOAS) is quite limited in terms of interactivity on the client. You can easily have an open/closed state, but as soon as you need something a bit more fancy, such as more complex states, animations or transitions, it falls short, as every small update relies on an external API.
HATEOAS is great when you need a standardized way to interact with dynamic data structures on a server. For example, it's great for a public API.
@pierrotlasticot5848 I’m managing the dropdown’s content via HTMX, not it’s open/closed state :)
@@KodapsAcademy ooh.. same here.. i misunderstood.. better work on my English...
@@pierrotlasticot5848 i misunderatood ... im managing the content inside dropdown ...
Make video on Remix Vs Nextjs
So now you use both react and htmx? Isn't that a very unnecessary bloat you claimed to try to avoid? I seriously don't understand your problem with updating these three unconected components when adding something to cart. React is 100% perfectly suited for this job. Just learn how to use context API in instead of throwing in another technology. Seriously react is like the #1 solution for stuff like this and you gave that as a reason to lean for another technology..
No you've misunderstood what I was saying. We don't use React on the page (we use it elsewhere, in the customer area), only HTMX. The rest of the page is rendered statically using PHP / Twig, not React. And React can't encompass those components that don't share a (HTML) parent unless we go via useRef. which would end up being an unnecessary complication. In any case, React was most certainly not the right tool for this use case.
I get your point that it would have been in a NextJS context, but it isn't here.
I would hardly call htmx "extra bloat"
@@KodapsAcademy "React can't encompass those components that don't share a (HTML) parent unless we go via useRef"
The lengths frontend devs will go to to avoid using an event bus is remarkable.
@@Jimbo-pf5lg as I described the whole point was to move the logic to the backend anyway
@@Jimbo-pf5lgsignals use them, that's why they're all adopting it
Laravel (Vue/React) Inertia
I’m not sure I understand the point you want to make ? Can you expand ?