2 ms·

Such error handling is easier, because it’s a normal part of the flow, rather than a separate path that’s not tested. If submitting fails to load the page, you

Such error handling is easier, because it’s a normal part of the flow, rather than a separate path that’s not tested. If submitting fails to load the page, you get the normal browser error page and reload, submitting it again. And that’s what you want it to be, unless you can actively do something else in the meantime (which is still a good deal more complex and not typically supported by web apps). By contrast, my experience says that scripting-based submission is very flimsy in the presence of unreliable network. It’s crazy just how many things enter broken, unrecoverable states because it didn’t occur to the authors that maybe that fetch could fail, and maybe you might want to try again. Or worse, and practically never handled properly, when network conditions lead to a stuck request, where the client is waiting for something that will never come. In the browser, you just press F5/Ctrl+R/⌘R when you recognise this situation, but when scripting-powered the only way of fixing this may be briefly toggling the network adapter in order to kill the request (because you can’t just reload the page because you’d lose in-page form state, another of these things that the browser gives you for free but scripting plays havoc with, though Firefox is best at compensating), and hoping that leads the page to let you submit again. Seriously, scripting-based submission, navigation, &c. is reimplementing a lot of what the browser give you for free, and it can’t be done perfectly (e.g. tab loading indicator) and what is reimplemented is absolutely never as flawless as possible. Yes, you get some interesting advantages, but you lose a lot too, more than developers tend to admit.

ivan_gammel 3y ago
>In the browser, you just press F5/Ctrl+R/⌘R Many users have no idea what does that mean and will just panic seeing the default error page. They will not read the message there and either will abandon the form, reach customer support or will restart their flow. You are absolutely right about the complexity of the form submission when network problems are taken into account, but default browser behavior isn't the best solution.
- chrismorgan 3y ago
  I suspect (though perhaps I’m naively optimistic) you may be doing the affected users an injustice. Most people will either practically never experience these error pages, or be familiar with them and their causes because they know their internet connection is dodgy at times. And the “Try Again” button’s pretty clear.
  - ivan_gammel 3y ago
    You will be indeed very optimistic to assume that generic „Try again“ is clear to everyone. In some cases the effects of it are unclear even to power users and they won’t click it. Let’s say I have got timeout page after clicking the final button in the checkout process: how do I know that it won’t place the order twice if I submit again? How do I know that it will submit it again correctly? After all, those timeouts happen often due to server-side delays. Today most people do not encounter those pages, because they interact with SPAs and more likely to encounter different error behavior. Good internet connection won’t prevent anything. Imagine a child accidentally unplugging the wifi router and grandma seeing the timeout page, because her browser doesn’t know that wifi is down. What she would do? This is the kind of situation IT support is dealing with regularly.

ivan_gammel 3y ago

>In the browser, you just press F5/Ctrl+R/⌘R Many users have no idea what does that mean and will just panic seeing the default error page. They will not read the message there and either will abandon the form, reach customer support or will restart their flow. You are absolutely right about the complexity of the form submission when network problems are taken into account, but default browser behavior isn't the best solution.

chrismorgan 3y ago
I suspect (though perhaps I’m naively optimistic) you may be doing the affected users an injustice. Most people will either practically never experience these error pages, or be familiar with them and their causes because they know their internet connection is dodgy at times. And the “Try Again” button’s pretty clear.
- ivan_gammel 3y ago
  You will be indeed very optimistic to assume that generic „Try again“ is clear to everyone. In some cases the effects of it are unclear even to power users and they won’t click it. Let’s say I have got timeout page after clicking the final button in the checkout process: how do I know that it won’t place the order twice if I submit again? How do I know that it will submit it again correctly? After all, those timeouts happen often due to server-side delays. Today most people do not encounter those pages, because they interact with SPAs and more likely to encounter different error behavior. Good internet connection won’t prevent anything. Imagine a child accidentally unplugging the wifi router and grandma seeing the timeout page, because her browser doesn’t know that wifi is down. What she would do? This is the kind of situation IT support is dealing with regularly.