Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx Is the Future

quii.dev

Post reply on HN
Print view View original

101–110 of 875 posts

Re: Htmx Is the Future

#101

Post by majormajor »

> 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.

Re: Htmx Is the Future

#102

Post by tgbugs »

I first encountered the principles behind htmx in its precursor intercooler.js. Those principles really resonated with my distaste for complexity. Amusingly I found out about htmx itself when rereading https://grugbrain.dev and it all clicked! htmx is crystal that trap internet complexity demon!

Re: Htmx Is the Future

#103

Post by geenat »

dfabulich wrote: post #56

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…

> it's impossible to implement "optimistic UI," where the user creates a TODO item on the client side and posts the data back to the server in the background.

Pretty common patterns for this- just use a sprinkle of client side JS (one of: hx-on, alpine, jquery, hyperscript, vanilla js, etc), then trigger an event for htmx to do its thing after awhile, or use the debounce feature if it's only a few seconds. Lots of options, actually.

React would have to eventually contact the server as well if we're talking about an equivalent app.

Re: Htmx Is the Future

#104

Post by elliottinvent »

danielvaughn wrote: post #94
obpe wrote: post #3

It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code fro…

100%. Saying that [technology x] will remove complexity is like saying that you've designed a house that can't get messy. All houses can be messy, all houses can be clean. It depends on the inhabitants.

True, but well designed houses that have natural places for the things a well functioning home needs, are far easier to keep clean and tidy.

Re: Htmx Is the Future

#105

Post by Alifatisk »

rektide wrote: post #2

Personally 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!

Re: Htmx Is the Future

#106

Post by renerick »

benatkin wrote: post #77
recursivedoubts wrote: post #65

Earlier quoted context omitted.

it absolutely is hypermedia we generalize HTML's hypermedia controls in the following way: - any HTML element can become a hypermedia control - any event can drive a hypermedia interaction - any element can be the target of a hypermedia interaction (transclusion, a concept in hypermedia not implemented by HTML) all server interactions are done in terms of hypermedia, just like w/links and forms it also makes PUT, PAT…

Links and forms are the bread and butter of many frameworks. Like with HTMX, SvelteKit and Remix forms won't function properly without the framework.

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.

Re: Htmx Is the Future

#107

Post by nologic01 »

htmx got a lot of good press (deservedly) but I think somehow it needs to get to the next step beyond the basic hypermedia evangelism. I don't know exactly what that step needs to be, because I don't know what a fully "htmx-ed" web would look like. It is promising, but that promise must be made more concrete.

A conceptual roadmap of where this journey could take us and, ideally, some production quality examples of solving important problems in a productive and fun way would increase the fan base and mindshare. Even better if it show how to solve problems we didn't know we had :-). I mean the last decade has been pretty boring in terms of opening new dimensions.

Just my two cents.

Re: Htmx Is the Future

#108

Post by sourcecodeplz »

optymizer wrote: post #52

I remember fetching HTML from the server with AJAX and updating innerHTML before it was called AJAX. Is HTMX repackaging that or am I missing some exciting breakthrough here?

It is like that yes but more abstract because it uses some special HTML tags to make the JS calls.

There is a big downside though: weak error handling. It just assumes that your call will get a response.

Re: Htmx Is the Future

#109

Post by pier25 »

obpe wrote: post #3

It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code fro…

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...

Re: Htmx Is the Future

#110

Post by yellowapple »

RHSeeger wrote: post #61
obpe wrote: post #3

It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code fro…

> We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace. Plus we now get the benefit of people trying to "replace" built in browser functionality with custom code, either The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. or They're changing things because they're already so far from def…

> There is a time and place for SPA (mail is a great example). But using them in places where the page reload would load in completely new content for most of the page anyways? That's paying a large cost for no practical benefit; and your users are paying some of that cost.

Yep. It's bonkers to me that a page consisting mostly of text (say, a Twitter feed or a news article) takes even so much as a second (let alone multiple!) to load on any PC/tablet/smartphone manufactured within the last decade. That latency is squarely the fault of heavyweight SPA-enabling frameworks and their encouragement of replacing the browser's features with custom JS-driven versions.

On the other hand, having to navigate a needlessly-elongated history due to every little action producing a page load (and a new entry in my browser's history, meaning one more thing to click "Back" to skip over) is no less frustrating. Neither is wanting to reload a page only for the browser to throw up scary warnings about resending information simply because that page happened to result from some POST'd form submission.

Everything I've seen of HTMX makes it seem to be a nice middle-ground between full-MPA v. full-SPA: each "screen" is its own page (like an MPA), but said page is rich enough to avoid full-blown reloads (with all the history-mangling that entails) for every little action within that page (like an SPA). That it's able to gracefully downgrade back to an ordinary MPA should the backend support it and the client require it is icing on the cake.

I'm pretty averse to frontend development, especially when it involves anything beyond HTML and CSS, but HTMX makes it very tempting to shift that stance from absolute to conditional.

Post reply on HN