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

301–310 of 326 posts

Re: Moving from React to htmx

#301

Post by graftak »

robertlagrant wrote: post #246
MatthiasPortzel wrote: post #41

Earlier quoted context omitted.

The slippery slope that scares me (as a React developer) about htmx (or Hotwire.dev, in particular is the one I was looking at), is that you start making the assumption that the client's internet is fast. There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rende…

I wouldn't assume a fragment is any bigger than the raw data when it's compressed. { "things": [ { "id": 183, "name": "The Thing", "some date": "2016-01-01", }, { "id": 184, "name": "The Other Thing", "some date": "2021-04-19", }, ]} Vs 183 The thing 2016-01-01 184 The other thing 2021-04-19 They seem extremely similar to me.

The issue with this model is that many state updates are not scoped to a single fragment. When you go to a another page, you’ll likely want to update the amount of results on one or more detached components. That’s way more natural to by getting the length of an array of data structures than on a html fragment.

Re: Moving from React to htmx

#302

Post by withinboredom »

ahungry wrote: post #296
withinboredom wrote: post #173

Earlier quoted context omitted.

I hate it when devs implement their own timeouts. That’s handled at the network level, and the socket knows if progress is being made. I was stuck using 2G data speeds for a couple of years and I loathed this behavior.

Sometimes the infrastructure causes this. For a long time (and now?) AWS Api Gateway has a hard cap of 30 seconds, so the sum of all hops along the way need to remain under that.

A timeout at that level should mean “no progress” for 30s, not that a request/response needs to finish in 30s. An naive timeout that a dev randomly implements might be the latter and would be the source of my past frustration.

Re: Moving from React to htmx

#303

Post by robertlagrant »

graftak wrote: post #301
robertlagrant wrote: post #246

Earlier quoted context omitted.

I wouldn't assume a fragment is any bigger than the raw data when it's compressed. { "things": [ { "id": 183, "name": "The Thing", "some date": "2016-01-01", }, { "id": 184, "name": "The Other Thing", "some date": "2021-04-19", }, ]} Vs 183 The thing 2016-01-01 184 The other thing 2021-04-19 They seem extremely similar to me.

The issue with this model is that many state updates are not scoped to a single fragment. When you go to a another page, you’ll likely want to update the amount of results on one or more detached components. That’s way more natural to by getting the length of an array of data structures than on a html fragment.

Possibly, yes, although many SPA sites seem to hit for updates every (visual) page change anyway, to get the latest results. It's rare that a UI will hold all the records to count locally, unless it's a small and slow-changing data set, so it's asking for a count whether or not it's getting it wrapped in HTML or JSON.

Re: Moving from React to htmx

#304

Post by recursivedoubts »

ChrisDevx wrote: post #300
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…

I have 2 problems with htmx (IMHO): 1. SoC: the server API needs to return only the data and meta data requested, and it should not be concerned with the display-layer (html), because many different clients i.e. mobile app, browser, Electron etc. might want to consume this API. 2. Logistics & scaling: Imagine a large application with 100s of html/htmx components and views, now you alter your database, you introduce n…

1. https://htmx.org/essays/locality-of-behaviour/

2. many large applications use htmx (or related approaches like hotwire, unpoly, etc.) and scale fine. hypermedia is better at handling databaase/logic/API changes than fixed-format data APIs because your API is encoded within hypermedia responses: https://htmx.org/essays/hateoas/

Re: Moving from React to htmx

#305

Post by ChrisDevx »

recursivedoubts wrote: post #304
ChrisDevx wrote: post #300

Earlier quoted context omitted.

I have 2 problems with htmx (IMHO): 1. SoC: the server API needs to return only the data and meta data requested, and it should not be concerned with the display-layer (html), because many different clients i.e. mobile app, browser, Electron etc. might want to consume this API. 2. Logistics & scaling: Imagine a large application with 100s of html/htmx components and views, now you alter your database, you introduce n…

1. https://htmx.org/essays/locality-of-behaviour/ 2. many large applications use htmx (or related approaches like hotwire, unpoly, etc.) and scale fine. hypermedia is better at handling databaase/logic/API changes than fixed-format data APIs because your API is encoded within hypermedia responses: https://htmx.org/essays/hateoas/

LoB yeah, on small scale perhaps, I guarantee you will end up with a cluttered mess on large applications, unless you spend a ton of extra time/work to design for scale, maintenance and dev onboarding.

I do not agree with HATEOAS, so now you have an API which job is to produce html (SoC problem), and what if a Flutter app also needs to consume this API, do you build another HATEOS API just for Flutter?

Every few years its the same, devs adopting and defending the new shiny thing, though I have to admit, I love that this time its a way more simplified, sane alternative.

Re: Moving from React to htmx

#306

Post by recursivedoubts »

ChrisDevx wrote: post #305
recursivedoubts wrote: post #304

Earlier quoted context omitted.

1. https://htmx.org/essays/locality-of-behaviour/ 2. many large applications use htmx (or related approaches like hotwire, unpoly, etc.) and scale fine. hypermedia is better at handling databaase/logic/API changes than fixed-format data APIs because your API is encoded within hypermedia responses: https://htmx.org/essays/hateoas/

LoB yeah, on small scale perhaps, I guarantee you will end up with a cluttered mess on large applications, unless you spend a ton of extra time/work to design for scale, maintenance and dev onboarding. I do not agree with HATEOAS, so now you have an API which job is to produce html (SoC problem), and what if a Flutter app also needs to consume this API, do you build another HATEOS API just for Flutter? Every few year…

I have experience with multiple large applications that use htmx. They scale fine. They just aren't what people are used to right now.

Give it time and mull it over. It may grow on you.

Re: Moving from React to htmx

#307

Post by miiiiiike »

recursivedoubts wrote: post #74
miiiiiike wrote: post #66

Earlier quoted context omitted.

I’ve used htmx.

I'm sure you have. Regardless of that, the idea that you learn htmx because don't want you to learn JavaScript is simply incorrect. Rather, it's how you use JavaScript that should be considered.

JSON APIs are usable beyond the browser and using htmx feels like using Django+jQuery 14 years ago. I'd rather not go back to that.

Re: Moving from React to htmx

#308

Post by yawaramin »

danieljacksonno wrote: post #144
yawaramin wrote: post #72

Earlier quoted context omitted.

Because migrating to NextJS would have meant doing a rewrite of the entire backend which was already written in Python/Django and running in production. Migrating to htmx was much less risky.

NextJS can use an external API? It doesn't need to be fully full-stack.

So then add Next.js when we're already using another backend service. The idea is to reduce complexity, not the other way round.

Re: Moving from React to htmx

#309

Post by qwertyzxcvmnbvw »

runald wrote: post #127
qwertyzxcvmnbvw wrote: post #71

Earlier quoted context omitted.

Side note: in Thailand and the Philippines, at least, mobile internet is blazing fast and not more expensive.

As someone living in one of those countries, I beg to differ. Cheap maybe, but mobile internet is neither fast nor stable.

I'm guessing that's Philippines :-] It's still been good enough for me to get work done, video calls, etc. And mostly better than hotel/coffee shop WiFi.

Re: Moving from React to htmx

#310

Post by recursivedoubts »

miiiiiike wrote: post #307
recursivedoubts wrote: post #74

Earlier quoted context omitted.

I'm sure you have. Regardless of that, the idea that you learn htmx because don't want you to learn JavaScript is simply incorrect. Rather, it's how you use JavaScript that should be considered.

JSON APIs are usable beyond the browser and using htmx feels like using Django+jQuery 14 years ago. I'd rather not go back to that.

cool cool

https://htmx.org/essays/splitting-your-apis/

https://htmx.org/essays/hypermedia-apis-vs-data-apis/

Post reply on HN