Moving from React to htmx
htmx.org
Moving from React to htmx
1–10 of 326 posts
Re: Moving from React to htmx
#2TLDR:
- Took 2 months (21K LoC, mostly JavaScript)
- No reduction in user experience
- Reduced LoC by 67% (21,500 LoC to 7200 LoC)
- They increased python by 140% (500 LoC to 1200 LoC), good if you prefer python to JS
- Reduced JS dependencies by 96% (255 to 9)
- Reduced web build time by 88% (40s to 5)
- First load time-to-interactive was reduced by 50-60% (from 2-6 seconds to 1-2 seconds)
- Much larger data sets were possible than react could handle
- Memory usage was reduced by 46% (75MB to 45MB)
These are spectacular numbers that reflect that the application in question is highly amenable to the hypermedia approach.
I wouldn't expect everyone to see this level of improvement, but at least some web apps would.
Re: Moving from React to htmx
#3TLDR: - Took 2 months (21K LoC, mostly JavaScript) - No reduction in user experience - Reduced LoC by 67% (21,500 LoC to 7200 LoC) - They increased python by 140% (500 LoC to 1200 LoC), good if you prefer python to JS - Reduced JS dependencies by 96% (255 to 9) - Reduced web build time by 88% (40s to 5) - First load time-to-interactive was reduced by 50-60% (from 2-6 seconds to 1-2 seconds) - Much larger data sets we…
[deleted]
Re: Moving from React to htmx
#4TLDR: - Took 2 months (21K LoC, mostly JavaScript) - No reduction in user experience - Reduced LoC by 67% (21,500 LoC to 7200 LoC) - They increased python by 140% (500 LoC to 1200 LoC), good if you prefer python to JS - Reduced JS dependencies by 96% (255 to 9) - Reduced web build time by 88% (40s to 5) - First load time-to-interactive was reduced by 50-60% (from 2-6 seconds to 1-2 seconds) - Much larger data sets we…
Speed is the big one for me. 2-6+ seconds is insanity for anything.
Re: Moving from React to htmx
#5TLDR: - Took 2 months (21K LoC, mostly JavaScript) - No reduction in user experience - Reduced LoC by 67% (21,500 LoC to 7200 LoC) - They increased python by 140% (500 LoC to 1200 LoC), good if you prefer python to JS - Reduced JS dependencies by 96% (255 to 9) - Reduced web build time by 88% (40s to 5) - First load time-to-interactive was reduced by 50-60% (from 2-6 seconds to 1-2 seconds) - Much larger data sets we…
Speed is the big one for me. 2-6+ seconds is insanity for anything.
Speed is definitely a big one.
I also am glad to see that everyone on the dev team became full stack developers, because I think the back-end/front-end split is often detrimental to development velocity. It's often better when a developer can fully realize an entire feature, with no front-end/back-end friction.
Re: Moving from React to htmx
#6One reason I prefer doing React is that retrofitting existing React stuff for React Native is better/easier than embarking on React Native from scratch.
Re: Moving from React to htmx
#7Love htmx and this talk is a brilliant run down of where it works well.
But as always it’s about choosing the right tool for the job. Server rendered pages/fragments solve so many issues around security and time to develop a product, however it only gets you so far.
Ultimately I think the decision when choosing a stack comes down to how much state you need to managed in browser. The vast majority of sites needs very little client side state management, htmx and other tools such as Alpine.js are perfect for this. But eventually as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework.
Now that doesn’t always mean going all in on a full SPA covering the whole of your product. It could just be a small fragment that requires that level of interaction.
Point is, don’t pick a tool because it’s “in vogue”, pick one because it lets you build the best possible product as efficiently as possible. For 80% of websites that could be htmx, and for the next 15% htmx probably works for 90% of their pages. It’s the 5% where htmx is not one of the right choices at all.
Re: Moving from React to htmx
#8It is a cliche but probably true: Second rewrite will be better by those sort of metrics even without a tech change. Lessons learned get applied. Domain is fully known.
I definitely believe in fewer LOC with any not-react due to all the hooks, memo, etc. boilerplate though!
Re: Moving from React to htmx
#9One reason I prefer doing React is that retrofitting existing React stuff for React Native is better/easier than embarking on React Native from scratch.
I would argue that most “apps” built with React Native don’t need to be apps at all, they are better as websites.
The majority of these apps are about placing the existing product into the App Store for discoverability, and encouraging users to be “locked” into the app at the expense of a worse customer experience.
A web app, in a browser, automatically has support for opening multiple pages as multiple tabs, bookmarks, sharing pages. You can’t do that with 99.9% of apps.
I will also argue strongly that, again, react native is unnecessary even if you do want to package a native app. WebView based apps perform as well as a react native app, and most of the time with significantly less additional code. It also forces you to up your “mobile website” UX. In general the minuet you build a mobile “app” the mobile web experience gets neglected.
Re: Moving from React to htmx
#10Love htmx and this talk is a brilliant run down of where it works well. But as always it’s about choosing the right tool for the job. Server rendered pages/fragments solve so many issues around security and time to develop a product, however it only gets you so far. Ultimately I think the decision when choosing a stack comes down to how much state you need to managed in browser. The vast majority of sites needs very…
I am in 100% agreement with you: pick the right tool for the job.
My hope is that, with htmx, HTML/hypermedia is that right tool for more jobs.