Less Htmx Is More

> In practice, this is virtually impossible to get right

Somehow every other JS frontend framework manages to hook into the History API just fine?

The way I read it is that there are frustrating edge cases that (at least the author) has run into, regularly, that would imply it's ... more difficult to custom handle that than to just let the browser do it.

They do, but mostly they make this work by recreating the entire frontend ecosystem within that framework. Mix-and-match a history-aware JS library from outside the framework's ecosystem, and you may find it's less robust than you expect.

What? They all butcher it. On a weekly basis I make the the mistake of clicking some link to a site and find I can't hit the back button to escape. Maybe this is technically the site developers' fault, not the library devs, but it's a lousy experience for users.

Sometimes it's definitely deliberate

My favourite part is when you middle click the link to be opened in a new tab to be read later to find out that it opens a bunch of main pages or nothing at all. That’s a top level UX.

The amount of times when I've clicked a link, hit the back button, nothing happens, I hit the back button again and I go 2 steps back in history...

Ever considered the website authors don't want you to go back? :-D

Heh ,I actually once added a bug like that too. Angular has "redirect" routes (path matches with redirect to a new path).

I didn't realize that this will make the back button effective unusable, because the redirected url will still be in the history unless you manually redirect with a bare component. Hence whenever someone used back, the redirect pushed them back to the route they just left. I just used it as I came from a backend perspective, where redirects are fine as there is a delay between the request and the redirect, giving the user the time to just double press back... Obviously not so with a JS redirect.

I believe that continues to be an angular Anti-Feature to date.(Just checked, they still have it in their docs - without the ability to surpress the redirected history entry as far as I can see)

I'm sure this move improves some engagement metric.

No I mean clicking a link that's part of the site's internal navigation. So like I'll click a link to go to a different part of the single-page application, then click the back button to get back to the previous place in the SPA, and the URL will change back but the page doesn't change.

More likely they didn't care and nobody wrote an automated test for it because that would be hard, no human testers are employed (because who even does that now?), and only two users got all the way through the labyrinthine process to report it as an issue so managers triaged the bug as wontfix.

I think this is industry standard practice in 2025, right?

It sounds like something you'd use for a POST route that served up html instead of JSON (weird for an app to do these days but it still happens). redirect-after-post is as old as the web (or at least the POST verb) and it actually _enhances_ the utility of the back button by removing the annoying prompt about re-posting.

Reddit history in the mobile website is terrible

> "[...] the redirected url will still be in the history unless you manually redirect with a bare component. Hence whenever someone used back, the redirect pushed them back to the route they just left."

I know this isn't technically a browser bug, but ever since this first became a problem that's somewhat common to find on various websites, a decade or so ago, I've wondered if browsers couldn't provide the solution nonetheless..

At the very least, detect the user behaviour that screams this problem is happening (multiple clicks of the back button, which each time lead to the user being redirected to the URL they were on when they clicked it - but maybe it would be OK to detect that on the first attempt too?), and then either automatically solve it by taking them back by two URLs rather than just to the previous one (while looking out for possibility of stacked redirects that might need to skip more than one redirecting URL), or provide an alert that this potential problem has been detected and giving the user a single click solution to use or ignore.

I feel like the automatic solution should work well, but I've not put much thought into this beyond what I've just written, so maybe somebody will point out why doing it automatically would be a problem - either because of difficulty in the browser being accurate in recognising when this problem needs a bypass solution, or because even when it has correctly spotted it there are scenarios I haven't thought of where the user wouldn't want the back button's default behaviour to change?

I know very little about web browser (or even general software) development, any chance somebody reading this could chime in on whether this feature would be hard to code, whether it might have any / too much of an impact on performance, and generally whether or not you think it's a good idea?

(And happy of course to hear answers to the "good idea?" question from anyone who's had this problem in a web browser, not just developers.)

I'm surprised you can tolerate the mobile website at all with the non stop full screen "better in the app" modals.

There are countless usecases for redirects.

A few examples of the top of my head:

when urls have changed,

when a resource/entity has been deleted,

when you wish to provide a unified entrypoint that sends users to another url so that you can easily change the redirection target in the future (i.e. redirecting a / to a /entities, so youre but blocking the / path if you want to add a homepage/landing page later)

I don't think I'd help with posts though. They do indeed usually send back a redirect - but the post is likely still in the history unless the website send it as AJAX/without a history entry (basically via JS fetch() instead of form action=)