HTMX is stand-alone from PostgREST, should be judged on its own interface and merits.

I’ve been using it to build a nontrivial site for a few months. It has some surprises coming from a background of experience with SPAs but it’s been pleasant to use overall, once I got over my own biases.

Not having to define types in JS is massive, and having a number of transitive frontend dependencies that I can count on one hand is huge.

It might not be the best tool for every job, but it’s a pretty great tool for small full stack shops.

I would argue the “more capable” frameworks, while invented with the best of intentions, have become unmanageable, unmaintainable monstrosities that just keep rolling out, as you put it, solutions in search of a problem.

htmx is not meant to do anything fancy that you can’t do with Ember/Angular/React/Vue/etc.

The main motives for me deciding to go with htmx:

- No duplication of data models and routing, and all business logic stays on the server-side where it belongs.

- Locality of behavior: you can see exactly where a request will be triggered and what will be done with the response, so less jumping between files or scrolling up and down.

- No build step, no dependency hell, and no outrageous churn; just include one JS file that browsers should be able to run indefinitely.

I'm thinking this is more interesting for admins who need common functions on top of their databases but don't want to deal with the cumbersome cli calls. Make a nice UI with the most used views and functions and you can ship it directly with the database, regardless of the stack above it. Your functions change when your admin tasks change or when your schema changes, not when the application has new requirements.

Many web sites don't have or need frameworks