5 ms·

Beyond these very limited examples I just cannot see any appeal of HTMX... The real world large web apps have a ton of state that needs to be updated, UI elemen

Beyond these very limited examples I just cannot see any appeal of HTMX... The real world large web apps have a ton of state that needs to be updated, UI elements that need to be swapped, multiple remote calls that need to be made on these actions. Why would you push all of that to the BE? A simple click is almost never just "delete a row": you need to update the row count in the UI, validate whether it's the last row and therefore can't be deleted, send a log message that pulls data from user state (are you going to construct this state in the API handler every time a row is deleted?), update a heavy graph that shows a visualization of the data in rows, etc... Maybe some very basic websites can survive with HTMX but that's incredibly not future-proof.

recursivedoubts 3y ago
in htmx you would do all that through a single action and target the area necessary to update if you had something like a count that was outside that area you could use an event, an out of band swap or just expand the target. we also have morph-based swaps that make it possible to retain more UI state while expanding the target area, if you'd like if you have some sort of visualization, you'd recompute it server side and stream it back, or use events to trigger an update adam james has done some cool stuff w/clojure and htmx visualizations: https://twitter.com/RustyVermeer/status/1701048955105391044 https://twitter.com/RustyVermeer/status/1701048955105391044 a little bit of hypermedia-friendly scripting can go a long way: https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ you are correct that htmx isn't for every application, but it can likely pull off a lot more than you think, and at much lower complexity levels than reactive options, which has been borne out by real world experience: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ as far as htmx being future-proof, I would point to it's predecessor, intercooler.js, which was released in 2013 and is still actively supported, simply because the code isn't hard to deal with. you could probably figure out and maintain htmx.js in a day or two, as a good JavaScript developer, something that can't be said for most other javascript frameworks.
- dragonelite 3y ago
  I started working in the early 2010s doing stuff on the backend was pretty normal with asp.net razor pages. Going from razor pages + jquery to AngularJs was one hell of transition. I think i can like HTMX because its backend agnostic just template it out and return the html. Given 99% of the angular work i do is "get the json, render the returned json to html in angular". I think HTMX can pretty much replace angular with those sort of tasks. That makes being full stack dev quiet easy only need to know my backend stuff, html(x), css(tailwind). Maybe you need some lightweight frontend state framework to do a bit more in the frontend. But its a shitload less to learn than angular, node, typescript, build tools etc etc.
  - kodapoda 3y ago
    I would argue that HTMLX is far less backend agnostic than something like React. In most cases, a React SPA just consumes an API. You could switch to an entirely different backend with no impact on the users. How easy would it be to migrate all your HTML templates to a different backend?
    - dragonelite 3y ago
      Well from experience backend tech stacks are way less mutable. But let assume you did want to change backend you will take into account your HTML templates and find the right template engine where you might just copy past your templates folder and do some light configuration work.. If that is not possible refactoring the templates parts shouldn't such a big issue. I see HTMX more as a way to keep far and far away from frontend frameworks, I can focus on being productive with Html, CSS and HTMX and call it a day. With react you need to learn HTML, CSS, moderate amount of javascript/typescript, state management, build tools etc etc. But you make a good point about React SPA just consuming json or whatever other non html data format.
    - recursivedoubts 3y ago
      essays related: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/two-approaches-to-decoupling/ https://htmx.org/essays/two-approaches-to-decoupling/

recursivedoubts 3y ago

in htmx you would do all that through a single action and target the area necessary to update if you had something like a count that was outside that area you could use an event, an out of band swap or just expand the target. we also have morph-based swaps that make it possible to retain more UI state while expanding the target area, if you'd like if you have some sort of visualization, you'd recompute it server side and stream it back, or use events to trigger an update adam james has done some cool stuff w/clojure and htmx visualizations: https://twitter.com/RustyVermeer/status/1701048955105391044 https://twitter.com/RustyVermeer/status/1701048955105391044 a little bit of hypermedia-friendly scripting can go a long way: https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ you are correct that htmx isn't for every application, but it can likely pull off a lot more than you think, and at much lower complexity levels than reactive options, which has been borne out by real world experience: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ as far as htmx being future-proof, I would point to it's predecessor, intercooler.js, which was released in 2013 and is still actively supported, simply because the code isn't hard to deal with. you could probably figure out and maintain htmx.js in a day or two, as a good JavaScript developer, something that can't be said for most other javascript frameworks.

dragonelite 3y ago
I started working in the early 2010s doing stuff on the backend was pretty normal with asp.net razor pages. Going from razor pages + jquery to AngularJs was one hell of transition. I think i can like HTMX because its backend agnostic just template it out and return the html. Given 99% of the angular work i do is "get the json, render the returned json to html in angular". I think HTMX can pretty much replace angular with those sort of tasks. That makes being full stack dev quiet easy only need to know my backend stuff, html(x), css(tailwind). Maybe you need some lightweight frontend state framework to do a bit more in the frontend. But its a shitload less to learn than angular, node, typescript, build tools etc etc.
- kodapoda 3y ago
  I would argue that HTMLX is far less backend agnostic than something like React. In most cases, a React SPA just consumes an API. You could switch to an entirely different backend with no impact on the users. How easy would it be to migrate all your HTML templates to a different backend?
  - dragonelite 3y ago
    Well from experience backend tech stacks are way less mutable. But let assume you did want to change backend you will take into account your HTML templates and find the right template engine where you might just copy past your templates folder and do some light configuration work.. If that is not possible refactoring the templates parts shouldn't such a big issue. I see HTMX more as a way to keep far and far away from frontend frameworks, I can focus on being productive with Html, CSS and HTMX and call it a day. With react you need to learn HTML, CSS, moderate amount of javascript/typescript, state management, build tools etc etc. But you make a good point about React SPA just consuming json or whatever other non html data format.
  - recursivedoubts 3y ago
    essays related: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/two-approaches-to-decoupling/ https://htmx.org/essays/two-approaches-to-decoupling/