> D*'s authors are pretty adamant that this is an anti-pattern

The Datastar authors are wrong about this. History push is a very important part of the hypermedia-driven application approach. Because URLs are super important. And we want to make sure that the correct URL is shown for the currently-loaded view, and that the view is reproducible given the URL (as much as possible) so that bookmarking and copy-pasting to send URLs just works as expected.

A really nice article came out about this just recently: https://alfy.blog/2025/10/31/your-url-is-your-state.html

I also wrote a bit more about it here: https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...

▲

nchmy 3 days ago | parent [-]

Thanks very much for a thoughtful reply and link to your article. I look forward to reading it.

As it turns out, I shared that very same article in the Datastar discord the other day! Here's some other good ones that I found while digging into the topic, for anyone who cares.

* https://warpspire.com/posts/url-design/

* https://blog.jim-nielsen.com/2023/examples-of-great-urls/

* https://www.w3.org/Provider/Style/URI

* https://www.hanselman.com/blog/urls-are-ui

I strongly agree that good urls are very important. But I don't see how D* prevents correct urls/history at all... You can click anchor links just fine for pages that are genuinely separate pages. If its just a sub page, filter etc, then i think in many cases it should only swap into the dom without updating the history.

Moreover, am I wrong to think that if you use hx-boost to swap in fragments, then the URL that gets updated/saved in history wouldn't actually load the same page if you loaded it from a bookmark? That wouldn't happen with non-boosted anchor links.

Anyway, I'm not the best person to take up this argument. If you are interested at all in some respectful debate on the topic, it would be great if you came by the datastar discord where there's definitely people who would be better able to engage with it. I'd be eager to observe from the sidelines

	▲	amanzi 3 days ago \| parent \| next [-]
		"Moreover, am I wrong to think that if you use hx-boost to swap in fragments, then the URL that gets updated/saved in history wouldn't actually load the same page if you loaded it from a bookmark? That wouldn't happen with non-boosted anchor links." It's a common pattern with Django and template partials that you check if the request is an AJAX request, in which case you just load a partial template to swap into the existing DOM. Or if it's not an AJAX request, your server-side logic loads the full template. A simple example would be a to-do list at http://example.com/todo/. Clicking on a task item would swap it into the DOM without a full page load, and then you'd update the URL and browser history to http://example.com/todo/my-task/. Then if you open that URL in a new session, your server side logic would render your page with the "my-task" already selected.
	▲	yawaramin 3 days ago \| parent \| prev [-]
		> If its just a sub page, filter etc, then i think in many cases it should only swap into the dom without updating the history. It depends. If it's a 'resource' (in the REST sense) then it should actually push the URL of the resource into history, because the URL should correspond to the currently viewed resource. This is exactly what I was talking about earlier, it's super important as a basic hypermedia principle. > if you use hx-boost to swap in fragments, then the URL that gets updated/saved in history wouldn't actually load the same page if you loaded it from a bookmark See amanzi's explanation or my blog post where I explain the same thing. With htmx we can easily check for the presence of a request header in the backend and serve the appropriate version of the resource: either a partial (fragment) rendering or a full page that contains the resource. I highly recommend reading my blog post: it's not a huge commitment and it will clarify these issues for you.