Less Htmx Is More

Sometimes it's definitely deliberate

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)

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.

> "[...] 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.)

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=)