I understand that for some messages, sure, you want an acknowledgement. I just don't see how that process is notably different for an async web client compared to what's already out there on desks and phones and particularly as compared to a blocking web UI.
If you had a blocking UI, any of those 'interruption' events could occur while you're staring at a spinner. And you (rightly) wouldn't know or feel confident that the message was sent until you re-established your connection and verified the item had made it to your sent items. Which is the same as it would be with an async client: it's an important email, so until you saw it in the Sent Items folder, you wouldn't have the warm-and-fuzzy feeling.
If your email never got sent to the server in the first place why could the website not use local storage to determine an error or not? Gmail uses constant POSTing with drafts here to solve that issue (not sure if it uses local storage).
I don't see why this UI couldn't show you a notification if Send was pressed and communication to the server wasn't successful. Especially since it is doing so much client side work already.
- I could quit my browser
- I could close my laptop
- If my train goes into a tunnel, I could lose my internet connection
…and I might never find out that the email didn’t make it, because my mail provider might never have found out that I was trying to send one. I need to know when the message is safely out of my hands.