ChrisDevx

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.

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.