3 ms·

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 displ

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 new business rules etc... If you used React or Alpinejs etc. you could just go to the relevant stores or app code and make the change as opposed to sifting and refactoring tons of html. Personally I'd rather just use Alpinejs from the start, knowing its lightweight, fast and easy to implement, and not end up painting myself into a corner over the application lifecycle.

recursivedoubts 4y ago
1. https://htmx.org/essays/locality-of-behaviour/ 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/ https://htmx.org/essays/hateoas/
- ChrisDevx 4y ago
  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.
  - recursivedoubts 4y ago
    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.

recursivedoubts 4y ago

1. https://htmx.org/essays/locality-of-behaviour/ 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/ https://htmx.org/essays/hateoas/

ChrisDevx 4y ago
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.
- recursivedoubts 4y ago
  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.