Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from React to htmx

htmx.org

Post reply on HN
Print view View original

11–20 of 326 posts

Re: Moving from React to htmx

#11

Post by recursivedoubts »

quickthrower2 wrote: post #8

It 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!

This wasn't a complete rewrite, it was a feature-for-feature rewrite of the front-end, moving from react to htmx, mainly as a proof of concept at first. Note that the amount of python actually increased, as logic was moved back to the server.

While I'm sure there were a few places where better decisions were made, I think it's reasonable to assume that the majority of the reduction in code is due to the different approach to front end development.

Re: Moving from React to htmx

#12

Post by andy800 »

samwillis wrote: post #7

Love 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…

> 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

I think that if you fully embrace HTMX's model, you can go far further than anticipated without a JS framework. Do you really need to be managing state on the client? Is it really faster to communicate via JSON, or protobuf, whatever, rather than atomic data and returning just small bits of replacement HTML -- inserted seamlessly that it's a better UI than many client-side components? Why have HTML elements react to changes in data or state, rather than just insert new HTML elements already updated with the new state?

I think you're describing a, let's do React in HTMX mindset, rather than let's go all in on the HTMX model. And I might be giving HTMX too much credit, but it has totally changed how I go about building web applications.

Re: Moving from React to htmx

#13

Post by keizo »

recursivedoubts wrote: post #5
keizo wrote: post #4

Earlier quoted context omitted.

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.

Oh for sure. For me programming is a hobby, so I can only get something made if I do it all.

Re: Moving from React to htmx

#15

Post by samwillis »

andy800 wrote: post #12
samwillis wrote: post #7

Love 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…

> 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 I think that if you fully embrace HTMX's model, you can go far further than anticipated without a JS framework. Do you really need to be managing state on the client? Is it really faster to communicate via JSON, or protobuf, whatever, rather than atomic data and returning j…

Oh, I completely agree with you. The vast VAST majority of sites don’t need that level of client side state management.

I’m currently working on a bio-informatics data modelling web app where htmx would not have been the right choice. But it’s in that 1-5% where that is the case. That’s kind of my point.

Outside of that project, I’m all in on the the HTMX model of server side rendered fragments.

Re: Moving from React to htmx

#16

Post by endisneigh »

serve side rendering is ideal, but at the end of the day what matters these days is developer productivity. a better question is how long it takes to make something like gmail with htmx vs. say react. you might say most apps are not gmail, and you'd be correct. so then you say, ok what about something like wikipedia? easy enough. then you start adding all of this javascript and it becomes a mess.

Re: Moving from React to htmx

#17

Post by funstuff007 »

keizo wrote: post #4
recursivedoubts wrote: post #2

TLDR: - 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.

I hear you, but YouTube takes 6+ seconds for me to load and it does not seem to hold them back. For most, not all, optimizing page load time is time probably best spent elsewhere. This is is no way to impugn htmx, because with htmx you seem to kill many birds with one stone.

Re: Moving from React to htmx

#18

Post by dhucerbin »

Listing template dependencies as event names that can change underlying data seems very brittle (hx-trigger for favorite articles). You would need at least integration tests to get some confidence! Can’t we infer used state in template and setup triggers for developer? LiveView gives better DX in this case.

Re: Moving from React to htmx

#19

Post by recursivedoubts »

gardenhedge wrote: post #14

I consider this an alternative development approach neither better or worse than what it is trying to replace. The winner in recent approach, imo, is Remix Run.

Reducing a code base by 2/3rds isn't better than what it replaced?

At least in some sense?

Re: Moving from React to htmx

#20

Post by jbverschoor »

andy800 wrote: post #12
samwillis wrote: post #7

Love 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…

> 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 I think that if you fully embrace HTMX's model, you can go far further than anticipated without a JS framework. Do you really need to be managing state on the client? Is it really faster to communicate via JSON, or protobuf, whatever, rather than atomic data and returning j…

Oh god please let’s not go back to JSF
Post reply on HN