Comment by chabska

12 days ago

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

    • 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?

    • 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.

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.

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.

  • 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.

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

      3 replies →

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.