3 ms·

> HTMX allows you to design pages that fetch fragments of HTML from your server to update the user's page as needed without the annoying full-page load refresh.

> HTMX allows you to design pages that fetch fragments of HTML from your server to update the user's page as needed without the annoying full-page load refresh. I've been on the sidelines for the better part of a decade for frontend stuff, but I was full-stack at a tiny startup in 2012ish that used Rails with partial fragments templates for this. It needed some more custom JS than having a "replacement target" annotation everywhere, but it was pretty straightforward, and provided shared rendering for the initial page load and these updates. So, question to those who have been active in the frontend world since then: that obviously failed to win the market compared to JS-first/client-first approaches (Backbone was the alternative we were playing with back then). Has something shifted now that this is a significantly more appealing mode? IIRC, one of the big downsides of that "partial" approach in comparison with SPA-approaches was that we had to still write those JSON-or-XML-returning versions of the endpoints as mobile clients became more prevalent. That seems like it would still be an issue here too.

dpistole 4y ago
From a front end perspective I think the selling points I see pitched for these new server side frameworks are "SEO" and "speed". SEO I personally think is a questionable motivation except in very specific use cases. Speed is almost compelling but the complexity cost and all the considerations around how a page is structured (which components are server, which are client, etc) does not seem worth the complexity cost IMO. Just pop a loading animation up in most cases IMO. I think I'm stuck somewhere in the middle between old-hacker-news-person yelling "lol were just back at index.html" and freshly-minted-youtube-devs going "this is definitely the new standard".
efields 4y ago
FE dev/manager here. I'll tackle this one out of order. > one of the big downsides of that "partial" approach in comparison with SPA-approaches was that we had to still write those JSON-or-XML-returning versions of the endpoints as mobile clients became more prevalent. That seems like it would still be an issue here too. Yup. Still, if you're at the scale where you need to support multiple clients, things should be going well enough where you can afford the extra work. As soon as multiple clients are involved, you're writing SOMETHING to support specifically that client. 10+ years ago, you'd be writing those extra conditionals to return JSON/XML _and_ someone is building out this non-browser client (mobile app, third party API, whatever). But you're not rearchitecting your browser experience so that's the tradeoff. > Has something shifted now that this is a significantly more appealing mode? React especially led from one promise to another about _how much less code_ you'd have to write to support a wide range of clients, when in reality there was always another configuration, another _something_ to maintain when new clients were introduced. On top of that, the mobile device libraries (React Native, etc), were always steps behind what a true native app UX felt like. I think a lot of us seasoned developers just feel burned by the SPA era. Because of how fast it is to iterate in js, places like npm would seemingly have just the right component needed to avoid having to build custom in-house, and its simply an `npm add` and an import away. Meanwhile, as the author states, React and company changed a lot under the hood rapidly, so dependencies would quickly become out of date, now trying to maintain a project full of decaying 3rd party libs because its own tech debt nightmare. Just for, say, popper.js or something like that. I'm just glad the community seems to actively be reconsidering "the old ways" as something valuable worth revisiting after learning what we learned in the last decade.

dpistole 4y ago

From a front end perspective I think the selling points I see pitched for these new server side frameworks are "SEO" and "speed". SEO I personally think is a questionable motivation except in very specific use cases. Speed is almost compelling but the complexity cost and all the considerations around how a page is structured (which components are server, which are client, etc) does not seem worth the complexity cost IMO. Just pop a loading animation up in most cases IMO. I think I'm stuck somewhere in the middle between old-hacker-news-person yelling "lol were just back at index.html" and freshly-minted-youtube-devs going "this is definitely the new standard".

efields 4y ago

FE dev/manager here. I'll tackle this one out of order. > one of the big downsides of that "partial" approach in comparison with SPA-approaches was that we had to still write those JSON-or-XML-returning versions of the endpoints as mobile clients became more prevalent. That seems like it would still be an issue here too. Yup. Still, if you're at the scale where you need to support multiple clients, things should be going well enough where you can afford the extra work. As soon as multiple clients are involved, you're writing SOMETHING to support specifically that client. 10+ years ago, you'd be writing those extra conditionals to return JSON/XML _and_ someone is building out this non-browser client (mobile app, third party API, whatever). But you're not rearchitecting your browser experience so that's the tradeoff. > Has something shifted now that this is a significantly more appealing mode? React especially led from one promise to another about _how much less code_ you'd have to write to support a wide range of clients, when in reality there was always another configuration, another _something_ to maintain when new clients were introduced. On top of that, the mobile device libraries (React Native, etc), were always steps behind what a true native app UX felt like. I think a lot of us seasoned developers just feel burned by the SPA era. Because of how fast it is to iterate in js, places like npm would seemingly have just the right component needed to avoid having to build custom in-house, and its simply an `npm add` and an import away. Meanwhile, as the author states, React and company changed a lot under the hood rapidly, so dependencies would quickly become out of date, now trying to maintain a project full of decaying 3rd party libs because its own tech debt nightmare. Just for, say, popper.js or something like that. I'm just glad the community seems to actively be reconsidering "the old ways" as something valuable worth revisiting after learning what we learned in the last decade.