3 ms·
HTMX (and similar) solves a lot of this. It so happens that we end up building two apps one frontend and one backend with SPAs as built today. I'd rather build
by throwaway7783 1y ago
HTMX (and similar) solves a lot of this. It so happens that we end up building two apps one frontend and one backend with SPAs as built today. I'd rather build a lot of it on the server side, and add some dumb interactivity on the client (show/hide, collapse/expand, effects). There is still a place for SPA though.
- naet 1y agoHTMX does the opposite of this, it requires many more round trips to the server instead of using client side JS to do work.
- throwaway7783 1y agoI meant for the SPA-like experience.
- aquariusDue 1y agoI find Datastar to be a better replacement for HTMX, especially now that it can also do plain requests instead of Server-Sent Events. You also don't need Alpine.js combined with HTMX anymore.
- chuckadams 1y agoFirst time I've heard of Datastar. Not sure what to make of it yet, but the video on data-star.dev is certainly one of the cutest things I've seen all year!
- goatlover 1y agoDoes it matter how many round trips are made to the server if they're fast enough to be seamless?
- princevegeta89 1y agoMany more round trips to the server is okay - it is the server after all and it is easy to scale it.
- recursivedoubts 1y agohtmx does not require many more round trips to the server, front end scripting is perfectly compatible with htmx: https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/ in addition to native html features like <details>, etc. htmx can often decrease the number of trips to a server because in the hypermedia model you are encouraged to deliver all the content for a UI in one fell swoop, rather than in a series of chatty JSON requests that may be made due to opaque reactive hooks.