Using an HTTP header to decide between "just return a snippet for this specific list element" v. "return the whole page with the updated content for this list element" is an interesting choice that I hadn't really considered before; normally I would've opted for two entirely separate routes (one for the full page, one for the specific hypermedia snippet), which HTMX also seems to support. I guess it ain't fundamentally different from using e.g. Accept-* headers for content negotiation.
Htmx Is the Future
141–150 of 875 posts
Re: Htmx Is the Future
#142Earlier quoted context omitted.
Alpine is a lightweight client side framework, not really at all equivalent to htmx.
I'm not sure what you mean. htmx and alpine.js are both client-side frameworks. To me, they seem to have similar goals and similar functionality. What do you see as the difference?
They're neither different nor similar. In fact they work together, with Alpine managing client side reactive state (NOT app state, just interaction) and htmx managing the actual request model. That's why the htmx docs often refer to Alpine. They should be used in combination, not to displace each other.
Re: Htmx Is the Future
#143Personally I believe strongly in thick clients but this is a pretty neat demo anyways. I see a lot of resemblance to http://catalyst.rocks with WebComponents that target other components. I think there's something unspoken here that's really powerful & interesting, which is the declarativization of the UI. We have stuff on the page, but making the actions & linkages of what does what to what has so far been trapped i…
That looks alot like Stimulus!
Yeah it is! I meant to cite that too. It's mentioned by Catalyst as inspiration, somewhere.
Re: Htmx Is the Future
#144Thanks for the reminder, I've been meaning to try it out. Just to get started, I asked ChatGPT to write an htmx app to show a 10-day weather forecast. It described the general steps and seemed to be able to describe how htmx works pretty well, including hx-get and hx-target, etc., but then said "As an AI language model, I am not able to write full applications with code". I replied "do the same thing in bash" (which…
You can write an htmx app in bash: https://www.youtube.com/watch?v=Jzcu4JheCtY
Re: Htmx Is the Future
#145i am the creator of htmx, this is a great article that touches on a lot of the advantages of the hypermedia approach (two big ones: simplicity & it eliminates the two-codebase problem, which puts pressure on teams to adopt js on the backend even if it isn't the best server side option) hypermedia isn't ideal for everything[1], but it is an interesting & useful technology and libraries like htmx make it much more rele…
Just started using HTMX on a new project and have been a big fan. I’d go so far as to say that it’s the best practical case for the theory of hypermedia in general. Like others have mentioned, this is the sort of thing that prob _should_ be in the HTML spec but, given what I’ve personally seen about the standards process, I have little expectation of seeing that. Thx again!
Re: Htmx Is the Future
#146Earlier quoted context omitted.
HTML forms absolutely do function without htmx since it's a part of browser standard. By default, htmx sends forms using same content type as browser does (application/x-www-form-urlencoded). The server will receive same requests, as if the browser sent them and can differentiate by presence of HX-Request HTTP header.
That's the properly part. If you make a form and the output is supposed to go in a particular place and it doesn't (hx-swap), then it isn't functioning properly. The degree to which it is improperly functioning depends on the UI and the user. In many cases it's improperly enough that it may as well either work or not work.
As mentioned, htmx will attach a `HX-Request: true` header to the request[1]. The server can check this header and either return a partial for swapping, or a full page/redirect like in good old days. Same with any request. This is one way of how htmx provides "progressive enhancement". Sure, this may not be as transparent, as other JS-first frameworks implement it, but it's not complex at all.
The only thing that might cause trouble is non-standard (as in HTML standard) HTTP methods, which basically means any method other than GET and POST, I admit that. However, the fact that these methods are not supported even in HTML5 is a huge miss.
Re: Htmx Is the Future
#147> 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" annota…
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.
Re: Htmx Is the Future
#148Earlier quoted context omitted.
I mean, there's nothing about an SPA that forces you to break the back button, to the contrary, it's possible to have a very good navigation experience and working bookmarks. But it takes some thinking to get it right.
I don’t think “forces” is the right way to think about it. By default a SPA breaks navigation history etc (it’s right in the name). It’s not onerous to reimplement it correctly but reimplement you must.
And it's very common for it to be re-implemented incorrectly.
Re: Htmx Is the Future
#149Earlier quoted context omitted.
I agree but one important point to consider is the dev effort of making a proper SPA which is not a very common occurrence. "The best SPA is better than the best MPA. The average SPA is worse than the average MPA." https://nolanlawson.com/2022/06/27/spas-theory-versus-practi...
Can we even weight that statement? The average SPA is significantly worse than the average MPA. There is so much browser functionality that needs to be replicated in a SPA that few teams have the resources or talent to do a decent job.
Yeah it's so easy to fuck it all up with an SPA.
Recently I was using Circle (like a paid social media platform for communities) and pressing back not only loses the scroll position, it loses everything. It basically reloads the whole home page.
Re: Htmx Is the Future
#150Earlier quoted context omitted.
I also switch back and forth between two large projects written in different decades and it definitely gives an interesting perspective on this. Basically every time I'm in php I go "oh yeah I see why we do react now" and every time I'm in react I go "oh right I see why php still exists."
To be fair to PHP there have been quite a few improvements to the language in recent years. I even hear Laravel is pretty nice to use. I'll never know that stuff though because the PHP I generally encounter is 15 years old spaghetti.
Yeah I also hear that and also have no idea because I'm permanently in that 5.6 shit.