3 ms·

There's a glaring issue with HTMX and I'm not sure how it can be resolved gracefully. Other related libraries solved this issue already (Turbo and Turbolinks).

There's a glaring issue with HTMX and I'm not sure how it can be resolved gracefully. Other related libraries solved this issue already (Turbo and Turbolinks). However, HTMX only returns HTML fragments and doesn't track head changes. It's not easy to explain.. but imagine if a user loads your webpage. Then the web page loads your assets are loaded (JS, CSS, etc). Then imagine a new deployment happens that introduces new styles and/or HTML for a given resource. The page that is loaded in the user's browser does not have the new styles and doesn't know they were updated. If the user interacts with the resource the page styles will break. This was fixed in Turbo and Turbolinks by introducing "data-turbo-track="true"" to a resource like a CSS sheet. When the server responds with a fresh page the head can be compared and a full reload can happen if the asset was updated. In HTMX, the page is just broken. edit: Currently, you would have to manually hack around this... like long polling for the current app version or returning it in every XHR request and adding a middleware to HTMX to do the check and pop up a "your page is out of date..." message.

naasking 3y ago
Not sure I get it. Non-immutable resources should be bundled as a URL that's a hash of the contents. Since htmx replies include updates to head, if the content changes then the URL changes, and head updates would update the URLs. Where's the issue? I can see you getting into a pickle if you don't bundle mutable resources, but that's why you should.
recursivedoubts 3y ago
it's true that htmx is mainly focused on partial HTML replacement and we usually recommend that people load javascript and CSS up up front and/or adopt inline scripting solutions for locality of behavior[1], but htmx also has a head-support extension: https://htmx.org/extensions/head-support/ https://htmx.org/extensions/head-support/ for htmx 2.0 i'm integrating this functionality into the core, it seems useful enough to be there. The extension is based on the head morphing algorithm of idiomorph: https://github.com/bigskysoftware/idiomorph/ https://github.com/bigskysoftware/idiomorph/ which 37Signals is going to integrate into Turbo for v8: https://twitter.com/ben_pylo/status/1717975035669876790 https://twitter.com/ben_pylo/status/1717975035669876790 [1] - https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/
- mortallywounded 3y ago
  I get it-- that will enable you to resolve the clash (or at least make it possible to detect and do something about it). However, it does feel messy/ugly when compared to how HTMX is generally portrayed (do some action, an HTML fragment in response). Now, you'll return an HTML fragment and/or an optional head element to merge? It feels a bit yucky, but I understand why it will be done. A cleaner approach may be leveraging the HX-Trigger response header in some way? I feel like the app version could be specified and if it changes, HTMX would know and could trigger an event that could be specified by the user. I don't really like either solution.. perhaps the head merging would be more correct, but damn it feels off =/
  - recursivedoubts 3y ago
    there are typically three major types of requests w/ htmx: - a full page request via an hx-boost, where head processing makes sense - a full page request via an hx-get, etc. where hx-select is used to pick out a piece, where head processing probably doesn't make sense - a partial of HTML, where head processing doesn't make sense we will optimize head support for the first case, hx-boost based requests, and make the latter cases possible via configuration if the user wants. htmx is much less opinionated than other frameworks on these things, i try to make it a hypermedia swiss army knife, which makes it a little ugly at times, but I don't like forcing people to do things a certain way for better or for worse using HX-Trigger to do a full page refresh on an application version change is a common pattern, but is something you would build on top of htmx, not something htmx would provide out of the box. it is focused on generalizing hypermedia controls and patching a few gaps in HTML, and that's about it.

naasking 3y ago

Not sure I get it. Non-immutable resources should be bundled as a URL that's a hash of the contents. Since htmx replies include updates to head, if the content changes then the URL changes, and head updates would update the URLs. Where's the issue? I can see you getting into a pickle if you don't bundle mutable resources, but that's why you should.

recursivedoubts 3y ago

it's true that htmx is mainly focused on partial HTML replacement and we usually recommend that people load javascript and CSS up up front and/or adopt inline scripting solutions for locality of behavior[1], but htmx also has a head-support extension: https://htmx.org/extensions/head-support/ https://htmx.org/extensions/head-support/ for htmx 2.0 i'm integrating this functionality into the core, it seems useful enough to be there. The extension is based on the head morphing algorithm of idiomorph: https://github.com/bigskysoftware/idiomorph/ https://github.com/bigskysoftware/idiomorph/ which 37Signals is going to integrate into Turbo for v8: https://twitter.com/ben_pylo/status/1717975035669876790 https://twitter.com/ben_pylo/status/1717975035669876790 [1] - https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/

mortallywounded 3y ago
I get it-- that will enable you to resolve the clash (or at least make it possible to detect and do something about it). However, it does feel messy/ugly when compared to how HTMX is generally portrayed (do some action, an HTML fragment in response). Now, you'll return an HTML fragment and/or an optional head element to merge? It feels a bit yucky, but I understand why it will be done. A cleaner approach may be leveraging the HX-Trigger response header in some way? I feel like the app version could be specified and if it changes, HTMX would know and could trigger an event that could be specified by the user. I don't really like either solution.. perhaps the head merging would be more correct, but damn it feels off =/
- recursivedoubts 3y ago
  there are typically three major types of requests w/ htmx: - a full page request via an hx-boost, where head processing makes sense - a full page request via an hx-get, etc. where hx-select is used to pick out a piece, where head processing probably doesn't make sense - a partial of HTML, where head processing doesn't make sense we will optimize head support for the first case, hx-boost based requests, and make the latter cases possible via configuration if the user wants. htmx is much less opinionated than other frameworks on these things, i try to make it a hypermedia swiss army knife, which makes it a little ugly at times, but I don't like forcing people to do things a certain way for better or for worse using HX-Trigger to do a full page refresh on an application version change is a common pattern, but is something you would build on top of htmx, not something htmx would provide out of the box. it is focused on generalizing hypermedia controls and patching a few gaps in HTML, and that's about it.