3 ms·

While cool as a proof of concept and kudos for execution, this looks like a nightmare to maintain for any non-trivial webapp.

robertlagrant 3y ago
It's definitely for websites or light apps only. There's a lot of mileage in that, though.
- leptons 3y ago
  The "light apps" that also require a database that don't have a more capable front-end framework seem to make HTMX look like a solution in search of a problem.
  - rakoo 3y ago
    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.
    - robertlagrant 3y ago
      Or even something like Django's admin interface could be implemented in htmx.
  - intrasight 3y ago
    Many web sites don't have or need frameworks
  - ralmidani 3y ago
    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.
  - gen220 3y ago
    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.
brodo 3y ago
I'm experimenting with it right now using Squitch [1] to make maintenance easier. It still feels like a hack and I also still have my doubts about the viability of this for real-world use. It's fun though and I'm learning about all kinds of advanced Postgres features. [1] https://sqitch.org/ https://sqitch.org/
agumonkey 3y ago
I'm honestly wondering what in our main web application would not be 100x easier using this.
crooked-v 3y ago
Well, for now, sure. Now we just need a way to compile and deploy HTMX routes to the database server as part of a CI process...
- deleted 3y ago
  [deleted]

robertlagrant 3y ago

It's definitely for websites or light apps only. There's a lot of mileage in that, though.

leptons 3y ago
The "light apps" that also require a database that don't have a more capable front-end framework seem to make HTMX look like a solution in search of a problem.
- rakoo 3y ago
  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.
  - robertlagrant 3y ago
    Or even something like Django's admin interface could be implemented in htmx.
- intrasight 3y ago
  Many web sites don't have or need frameworks
- ralmidani 3y ago
  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.
- gen220 3y ago
  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.

brodo 3y ago

I'm experimenting with it right now using Squitch [1] to make maintenance easier. It still feels like a hack and I also still have my doubts about the viability of this for real-world use. It's fun though and I'm learning about all kinds of advanced Postgres features. [1] https://sqitch.org/ https://sqitch.org/

agumonkey 3y ago

I'm honestly wondering what in our main web application would not be 100x easier using this.

crooked-v 3y ago

Well, for now, sure. Now we just need a way to compile and deploy HTMX routes to the database server as part of a CI process...

deleted 3y ago
[deleted]