Comment by recursivedoubts | Hacker News Reader

Comment by recursivedoubts | Hacker News Reader

Parent Full thread

recursivedoubts

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

a little bit of hypermedia-friendly scripting can go a long way:

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/

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.

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.

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?

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.

essays related:

https://htmx.org/essays/splitting-your-apis/

https://htmx.org/essays/two-approaches-to-decoupling/

Reply on news.ycombinator.com