8 ms·

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 argume

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 Turbolinks is more than ten years old. React was born and rose to popularity during the age of Turbolinks. Turbolinks has already lost the war against React. The biggest problem with Turbolinks/Htmx is that there's no good story for what happens when one component in a tree needs to update another component in the tree. (Especially if it's a "second cousin" component, where your parent component's parent component has subcomponents you want to update.) EDIT: I know about multi-swap. https://htmx.org/extensions/multi-swap/ https://htmx.org/extensions/multi-swap/ It's not good, because the onus is on the developer to compute which components to swap, on the server side, but the state you need is usually on the client. If you need multi-swap, you'll find it orders of magnitude easier to switch to a framework where the UI is a pure function of client-side state, like React or Svelte. Furthermore, in Turbolinks/Htmx, 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. This means that the user always has to wait for a server round trip to create a TODO item, hurting the user experience. It's unacceptable on mobile web in particular. When predicting the future, I always look to the State of JS survey https://2022.stateofjs.com/en-US/libraries/front-end-frameworks/ https://2022.stateofjs.com/en-US/libraries/front-end-framewo... which asks participants which frameworks they've heard of, which ones they want to learn, which ones they're using, and, of the framework(s) they're using, whether they would use it again. This breaks down into Awareness, Usage, Interest, and Retention. React is looking great on Usage, and still pretty good on Retention. Solid and Svelte are the upstarts, with low usage but very high interest and retention. Htmx doesn't even hit the charts. The near future is React. The further future might be Svelte or Solid. The future is not Htmx.

recursivedoubts 3y ago
never tell me the odds, kid https://htmx.org/img/memes/whowillwin.png https://htmx.org/img/memes/whowillwin.png
OliverM 3y ago
I've not used Htmx, but a cursory browse of their docs gives https://htmx.org/extensions/multi-swap/ https://htmx.org/extensions/multi-swap/ which seems to solve exactly this problem. And thinking about it, what makes it as difficult as you say? If you've a js-library on the client you control you can definitely send payloads that library could interpret to replace multiple locations as needed. And if the client doesn't have js turned on the fallback to full-page responses solves the problem by default. Of course, I've not used Turbolinks, so I don't know what issues applied there. Edit: I'm not saying htmx is the future either. I'd love to see how they handle offline-first (if at all) or intermittent network connectivity. Currently most SPAs are bad at that too...
- dfabulich 3y ago
  I've edited my post to clarify. Multi-swap is possible, but it's not good, because the onus is on the developer to compute which components to swap, on the server side, but the state you need is usually on the client. If you need multi-swap, you'll find it orders of magnitude easier to switch to a framework where the UI is a pure function of client-side state, like React or Svelte.
  - nymanjon 3y ago
    You should be able to do this with events in HTMX also. So, you could do an update or create something and then in HTMX capture the event and reload the component when that happens.
geenat 3y ago
> 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.
yawaramin 3y ago
> there's no good story for what happens when one component in a tree needs to update another component in the tree. Huh, no one told me this before, so I've been very easily doing it with htmx's 'out of band swap' feature. If only I'd known before that it was impossible! ;-)
jgoodhcg 3y ago
I've spent almost my entire career working on react based SPAs and react native mobile apps. I've just started playing around with HTMX. > no good story for what happens when one component in a tree needs to update another component in the tree HTMX has a decent answer to this. Any component can target replacement for any other component. So if the state of everything on the page changes then re-render the whole page, even if what the user clicked on is a button heavily nested. > it's impossible to implement "optimistic UI," ... hurting the user experience Do we actually need optimistic UI? Some apps need to work in offline mode sure, like offline maps or audiobooks or something. The HTMX author agrees, this is not the solution for that. Most of the stuff I have worked on though ... is useless without an internet connection. In the case of "useless without internet connection" do we really need optimistic UI. The actual experience of htmx is incredibly fast. There is no overhead of all the SPA stuff. No virtual dom, hardly any js. It's basically the speed of the network. In my limited practice I've actually felt the need to add delays because the update happens _too fast_. I'm still evaluating htmx but not for any of the reasons you've stated. My biggest concern is ... do I want my api to talk in html?
- recursivedoubts 3y ago
  > do I want my api to talk in html https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/
  - jgoodhcg 3y ago
    One great thing about your docs is the anticipation to concerns.
    - CRConrad 3y ago
      “So if they try this, then what can go wrong? And then if they do that, what next....?” Must be why they're called “Recursive Doubts”.
- dfabulich 3y ago
  > Do we actually need optimistic UI? Some apps need to work in offline mode sure, like offline maps or audiobooks or something. The HTMX author agrees, this is not the solution for that. Most of the stuff I have worked on though ... is useless without an internet connection. > It's basically the speed of the network. Does your stuff work on mobile web? Mobile web requests can easily take seconds, and on a dodgy connection, a single small request can often take 10+ seconds. The difference between optimistic UI and non-optimistic UI on mobile web is the difference between an app that takes seconds to respond, on every click, and one that responds instantly to user gestures.
listenallyall 3y ago
Intentionally or not, this doesn't read like a cogent argument against the merits of HTMX (and isn't, since it is factually incorrect) but just as a person who is trying to convince him/herself that his/her professional skill set isn't starting to lose relevance. From the February 31, 1998 Hacker News archives: "According to state of the web survey, Yahoo and Altavista are looking great on usage, Hotbot and AskJeeves are the upstarts. Google doesn't even hit the charts."
qgin 3y ago
It's interesting that this paradigm is especially popular on Hacker News. I see it pop up here pretty regularly and not many other places.
- antoniuschan99 3y ago
  lol HN itself seems like it should be the poster child of htmx :P. It's literally just text.
deltarholamda 3y ago
I guess it depends on what your definition of "the future" is. If it's teams of 10X devs working around the world to make the next great Google-scale app, then yeah, maybe React or something like it is the future. If it's a bunch of individual devs making small things that can be tied together over the old-school Internet, then something like HTMX moves that vision forward, out of a 90-00s page-link, page-link, form-submit flow. Of course, the future will be a bit of both. For many of my various project ideas, something like React is serious overkill. Not even taking into account the steep learning curve and seemingly never-ending treadmill of keeping current.
BeefySwain 3y ago
The people using HTMX have never heard of stateofjs.com (though they are painfully aware of the state of js!)
antoniuschan99 3y ago
But isn't React going this route as well? There was some talk a week or so back with the React team talking about this direction. Also, it seems so cyclic, isn't HTMX/Hotwire similar to Java JSP's which was how things were before SPA's got popular?
jbergens 3y ago
Of course there are some challenges and some use cases where Htmx is not the best solution but I think it can scale pretty far. You can split a large app into pages and then each page only has to care about its own parts (sub components). If you want some component to be used on multiple pages you just create it with the server technology you use and include it. The other components on the page can easily target it. You may have some problem if you change a shared component in such a way that targeting stops working. You may be able to share the targeting code to make this easier.
wibblewobble124 3y ago
we’re using htmx at work, migrating away from react. the technique we’re using is just rendering the whole page, e.g. we have a page where one side of the screen is a big form and the other side is a view on the same data but with a different UI, updating one updates the other. we’re using the morphdom swapping mode so only the things that changed are updated in-place. as a colleague commented after implementing this page, it was pretty much like react as far as “pure function of state.”

recursivedoubts 3y ago

never tell me the odds, kid https://htmx.org/img/memes/whowillwin.png https://htmx.org/img/memes/whowillwin.png

OliverM 3y ago

I've not used Htmx, but a cursory browse of their docs gives https://htmx.org/extensions/multi-swap/ https://htmx.org/extensions/multi-swap/ which seems to solve exactly this problem. And thinking about it, what makes it as difficult as you say? If you've a js-library on the client you control you can definitely send payloads that library could interpret to replace multiple locations as needed. And if the client doesn't have js turned on the fallback to full-page responses solves the problem by default. Of course, I've not used Turbolinks, so I don't know what issues applied there. Edit: I'm not saying htmx is the future either. I'd love to see how they handle offline-first (if at all) or intermittent network connectivity. Currently most SPAs are bad at that too...

dfabulich 3y ago
I've edited my post to clarify. Multi-swap is possible, but it's not good, because the onus is on the developer to compute which components to swap, on the server side, but the state you need is usually on the client. If you need multi-swap, you'll find it orders of magnitude easier to switch to a framework where the UI is a pure function of client-side state, like React or Svelte.
- nymanjon 3y ago
  You should be able to do this with events in HTMX also. So, you could do an update or create something and then in HTMX capture the event and reload the component when that happens.

geenat 3y ago

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

yawaramin 3y ago

> there's no good story for what happens when one component in a tree needs to update another component in the tree. Huh, no one told me this before, so I've been very easily doing it with htmx's 'out of band swap' feature. If only I'd known before that it was impossible! ;-)

jgoodhcg 3y ago

I've spent almost my entire career working on react based SPAs and react native mobile apps. I've just started playing around with HTMX. > no good story for what happens when one component in a tree needs to update another component in the tree HTMX has a decent answer to this. Any component can target replacement for any other component. So if the state of everything on the page changes then re-render the whole page, even if what the user clicked on is a button heavily nested. > it's impossible to implement "optimistic UI," ... hurting the user experience Do we actually need optimistic UI? Some apps need to work in offline mode sure, like offline maps or audiobooks or something. The HTMX author agrees, this is not the solution for that. Most of the stuff I have worked on though ... is useless without an internet connection. In the case of "useless without internet connection" do we really need optimistic UI. The actual experience of htmx is incredibly fast. There is no overhead of all the SPA stuff. No virtual dom, hardly any js. It's basically the speed of the network. In my limited practice I've actually felt the need to add delays because the update happens _too fast_. I'm still evaluating htmx but not for any of the reasons you've stated. My biggest concern is ... do I want my api to talk in html?

recursivedoubts 3y ago
> do I want my api to talk in html https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/
- jgoodhcg 3y ago
  One great thing about your docs is the anticipation to concerns.
  - CRConrad 3y ago
    “So if they try this, then what can go wrong? And then if they do that, what next....?” Must be why they're called “Recursive Doubts”.
dfabulich 3y ago
> Do we actually need optimistic UI? Some apps need to work in offline mode sure, like offline maps or audiobooks or something. The HTMX author agrees, this is not the solution for that. Most of the stuff I have worked on though ... is useless without an internet connection. > It's basically the speed of the network. Does your stuff work on mobile web? Mobile web requests can easily take seconds, and on a dodgy connection, a single small request can often take 10+ seconds. The difference between optimistic UI and non-optimistic UI on mobile web is the difference between an app that takes seconds to respond, on every click, and one that responds instantly to user gestures.

listenallyall 3y ago

Intentionally or not, this doesn't read like a cogent argument against the merits of HTMX (and isn't, since it is factually incorrect) but just as a person who is trying to convince him/herself that his/her professional skill set isn't starting to lose relevance. From the February 31, 1998 Hacker News archives: "According to state of the web survey, Yahoo and Altavista are looking great on usage, Hotbot and AskJeeves are the upstarts. Google doesn't even hit the charts."

qgin 3y ago

It's interesting that this paradigm is especially popular on Hacker News. I see it pop up here pretty regularly and not many other places.

antoniuschan99 3y ago
lol HN itself seems like it should be the poster child of htmx :P. It's literally just text.

deltarholamda 3y ago

I guess it depends on what your definition of "the future" is. If it's teams of 10X devs working around the world to make the next great Google-scale app, then yeah, maybe React or something like it is the future. If it's a bunch of individual devs making small things that can be tied together over the old-school Internet, then something like HTMX moves that vision forward, out of a 90-00s page-link, page-link, form-submit flow. Of course, the future will be a bit of both. For many of my various project ideas, something like React is serious overkill. Not even taking into account the steep learning curve and seemingly never-ending treadmill of keeping current.

BeefySwain 3y ago

The people using HTMX have never heard of stateofjs.com (though they are painfully aware of the state of js!)

antoniuschan99 3y ago

But isn't React going this route as well? There was some talk a week or so back with the React team talking about this direction. Also, it seems so cyclic, isn't HTMX/Hotwire similar to Java JSP's which was how things were before SPA's got popular?

jbergens 3y ago

Of course there are some challenges and some use cases where Htmx is not the best solution but I think it can scale pretty far. You can split a large app into pages and then each page only has to care about its own parts (sub components). If you want some component to be used on multiple pages you just create it with the server technology you use and include it. The other components on the page can easily target it. You may have some problem if you change a shared component in such a way that targeting stops working. You may be able to share the targeting code to make this easier.

wibblewobble124 3y ago

we’re using htmx at work, migrating away from react. the technique we’re using is just rendering the whole page, e.g. we have a page where one side of the screen is a big form and the other side is a view on the same data but with a different UI, updating one updates the other. we’re using the morphdom swapping mode so only the things that changed are updated in-place. as a colleague commented after implementing this page, it was pretty much like react as far as “pure function of state.”