4 ms·

Breaking the back button is not SPA behavior.

by robertoandred 4y ago

hansvm 4y ago
It's a common behavior in SPA that's uncommon elsewhere. Kind of like how buffer overflows aren't C behavior.
- andrewstuart2 4y ago
  I've had at least as many WebApps I've used built with JSP or ASP et al that broke back via unrepeatable POSTs and server side state as I have with SPAs.
icedchai 4y ago
It’s very common in poorly engineered SPAs. “Built in” browser functionality often has to be reimplemented.
- Mo3 4y ago
  Bad developers are still not a valid argument against SPAs.
  - Taywee 4y ago
    Why not? "You have to reimplement a huge amount of current and future behaviors that just work for MPAs" is definitely an argument against SPAs. That's extra work, extra potential for bugs, extra potential for accessibility problems.
  - dempseye 4y ago
    That's like saying bad trapeze artists are not a valid argument for safety nets.
  - RHSeeger 4y ago
    If it is more common for functionality to be broken in an SPA than in a non-SPA, then that most certainly _is_ a valid argument against SPAs (from a user perspective). It's not an argument that all SPAs are bad. Rather, that I prefer non-SPA implementations because I can generally assume that it will have fewer bugs/annoyances in using it.
  - layer8 4y ago
    It sort-of is if bad developers are less likely to wreck havoc with MPAs. Also, I don’t think that back-button breakage automatically indicates incompetent developers (although I tend to swear at them).
RHSeeger 4y ago
While I agree that the back button _should_ work in an SPA, it's common for it not to. And it's common for other functionality to break. It's not hard to fix that and, for a well engineered SPA, such things typically do work. However, it _is_ extra work and it _does_ get missed. As such, SPAs tend to have more issues than non-SPAs. As such, as a user, I tend to prefer non-SPA implementations unless there is a strong reason that the SPA makes more sense.
trivialsoup 4y ago
Not only is it not implicitly SPA behavior, as you say, good back button behavior design is actually hard in a app setting. And you can’t generally “get it right” — no matter what you do, in a sufficiently complex scenario (which… that’s why you built an SPA, right?) users will disagree about what the back button should do! Generalized anti-SPA sentiment is silly. Saying “bad implementations correspond with SPA” is true but also silly because there’s not as much to get wrong in non-app settings which admit a “traditional” approach. It’s like the xkcd observation about heat maps and population density.
- throwaway1851 4y ago

Breaking the back button is not SPA behavior.

hansvm 4y ago

It's a common behavior in SPA that's uncommon elsewhere. Kind of like how buffer overflows aren't C behavior.

andrewstuart2 4y ago
I've had at least as many WebApps I've used built with JSP or ASP et al that broke back via unrepeatable POSTs and server side state as I have with SPAs.

icedchai 4y ago

It’s very common in poorly engineered SPAs. “Built in” browser functionality often has to be reimplemented.

Mo3 4y ago
Bad developers are still not a valid argument against SPAs.
- Taywee 4y ago
  Why not? "You have to reimplement a huge amount of current and future behaviors that just work for MPAs" is definitely an argument against SPAs. That's extra work, extra potential for bugs, extra potential for accessibility problems.
- dempseye 4y ago
  That's like saying bad trapeze artists are not a valid argument for safety nets.
- RHSeeger 4y ago
  If it is more common for functionality to be broken in an SPA than in a non-SPA, then that most certainly _is_ a valid argument against SPAs (from a user perspective). It's not an argument that all SPAs are bad. Rather, that I prefer non-SPA implementations because I can generally assume that it will have fewer bugs/annoyances in using it.
- layer8 4y ago
  It sort-of is if bad developers are less likely to wreck havoc with MPAs. Also, I don’t think that back-button breakage automatically indicates incompetent developers (although I tend to swear at them).

RHSeeger 4y ago

While I agree that the back button _should_ work in an SPA, it's common for it not to. And it's common for other functionality to break. It's not hard to fix that and, for a well engineered SPA, such things typically do work. However, it _is_ extra work and it _does_ get missed. As such, SPAs tend to have more issues than non-SPAs. As such, as a user, I tend to prefer non-SPA implementations unless there is a strong reason that the SPA makes more sense.

trivialsoup 4y ago

Not only is it not implicitly SPA behavior, as you say, good back button behavior design is actually hard in a app setting. And you can’t generally “get it right” — no matter what you do, in a sufficiently complex scenario (which… that’s why you built an SPA, right?) users will disagree about what the back button should do! Generalized anti-SPA sentiment is silly. Saying “bad implementations correspond with SPA” is true but also silly because there’s not as much to get wrong in non-app settings which admit a “traditional” approach. It’s like the xkcd observation about heat maps and population density.

throwaway1851 4y ago