The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used.
The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly showing a loading spinner in the interim).
Facebook Messenger has the best UX paradigm for this I've seen, since it's most graceful in handling the edge case failures while still presenting as optimistic. Your message immediately appears as a conversation bubble, with an icon displaying if the server has received it, an 'X' if it fails (clicking the icon gives you options: re-send, delete, etc), and a read receipt for when the other party views the message. It's a fantastic way of handling the lifecycle.
Slack fails because it doesn't communicate that pending, the-server-hasn't-received-it-yet status, and the fallback isn't as graceful.
The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly showing a loading spinner in the interim).
Facebook Messenger has the best UX paradigm for this I've seen, since it's most graceful in handling the edge case failures while still presenting as optimistic. Your message immediately appears as a conversation bubble, with an icon displaying if the server has received it, an 'X' if it fails (clicking the icon gives you options: re-send, delete, etc), and a read receipt for when the other party views the message. It's a fantastic way of handling the lifecycle.
Slack fails because it doesn't communicate that pending, the-server-hasn't-received-it-yet status, and the fallback isn't as graceful.