React vs HTMX: Why we chose HTMX?
Vložit
- čas přidán 26. 05. 2024
- In the HTMX vs React debate, we made a difference choice. At EcoTree, an e-commerce site with a PHP backend using Symfony, we needed to manage a customer's shopping basket efficiently. For our customer area, React provided the necessary intricate interactions and polished user experience, especially since it’s behind an authentication gate and not intended for search engine indexing. However, for the rest of the website, which needed to be indexed by Google, server-side rendering with Symfony’s templating engine (Twig) was more suitable to ensure fast page loads and better SEO performance.
However, we faced issues with an outdated jQuery library called SimpleCart, which managed the shopping basket locally on the client’s browser. This method prevented us from knowing if users had issues during checkout or if items in their basket were about to sell out, as this information was not stored on the server. We explored three solutions: server-side rendering, React, and HTMX. Server-side rendering would result in a poor user experience due to full-page reloads, and React, although powerful, could lead to a bloated bundle and slow page loads. HTMX emerged as the optimal solution, allowing us to update parts of the interface based on server-side logic without reloading the page, thus providing a smooth user experience and maintaining fast load times for SEO.
Choosing between HTMX and React depends on the specific requirements of the project. Use React for complex, interactive interfaces that demand immediate feedback and where interactivity is crucial. React is ideal for applications behind authentication gates where SEO is not a primary concern. In contrast, HTMX is beneficial for managing server-side state updates on static pages, connecting different UI elements without the overhead of a full-page reload. HTMX ensures fast load times essential for SEO while still allowing partial updates based on server responses. At EcoTree, HTMX was the better solution for updating the shopping basket across different pages, providing a seamless user experience and improving our ability to track user interactions and inventory status on the server. This approach demonstrated that a hybrid solution, leveraging both HTMX and React based on context-specific needs, can offer the best of both worlds in web development.
----
Want to go into further depth? Head to kodaps.dev/ - Věda a technologie
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.
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.
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.
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).
This is a better use case for web components.
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 »)
Great explanation
Greate example!
Thanks :)
Hotwired Turbo plus AlpineJS have brilliant balance.
Make video on Remix Vs Nextjs
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 ...
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 !
🌟 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!
Laravel (Vue/React) Inertia
I’m not sure I understand the point you want to make ? Can you expand ?
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