Comment by can3p
12 days ago
There are two sides to the argument which I think should be treated separately: a) Is it a good idea overall? and b) is htmx implementation good enough?
a) I think so, yes. I've seen much more spa that have a completely broken page navigation. This approach does not fit all use cases, but if you remember that the whole idea of htmx is that you rely on webserver giving you page updates as opposed to having a thick js app rendering it all the way it makes sense. And yes, js libraries should be wrapped to function properly in many cases, but you would do the same with no react-native components in any react app for example
b) I don't think so. htmx boost functionality is an afterthought and it will always be like this. Compare it with turbo [1] where this is a core feature and the approach is to use turbo together with stimulus.js which gives you automagical component life cycle management. Turbo still has it's pains (my favorite gh issue [2]), but otherwise it works fine
[1]: https://turbo.hotwired.dev/ [2]: https://github.com/hotwired/turbo/issues/37
htmx boost functionality is an afterthought in the main use case it is marketed for (turning a traditional MPA into something that feels like a SPA), but it's actually super useful for the normal htmx use case of fetching partial updates and swapping them into a page.
If you do something like <a href=/foo hx-get=/foo hx-target="#foo">XYZ</a> the intention is that it should work with or without JavaScript or htmx available. But the problem is that if you do Ctrl-click or Cmd-click, htmx swallows the Ctrl/Cmd key and opens the link in the same tab instead of in a new tab!
But if you do <a href=/foo hx-boost=true hx-target="#foo">XYZ</a> everything works as expected–left-click does the swap in the current tab as expected, Ctrl/Cmd-click opens in a new tab, etc. etc.
Also another point–you are comparing htmx's boost, one feature out of many, to the entirety of Turbo? That seems like apples and oranges.
hx-boost is an afterthought and we haven't pushed the idea further because we expect view transitions via normal navigation to continue to fill in that area
htmx focuses on generalizing hypermedia controls:
https://dl.acm.org/doi/pdf/10.1145/3648188.3675127
we also have a minimalist version of the idea, fixi:
https://github.com/bigskysoftware/fixi
Thanks for the correction!
Would like to second the turbo rec. I've had good results with it for nontrivial use cases. Would like to hear from people if they have different experiences. Also, praying that everything gets cached first load and hand waving that view transitions will eventually work is not a position I want to hear from an engineer in a commercial context. Really happy to see the author bring more attention to how good vanilla web technologies have gotten though.