Alright, to be fair, if you change anything at all in your application, you need write code. However, instead of spending two weeks and rebuilding everything under the sun, this change only required a quick update to how messages get posted.
To be precise, we do two things different now:
(1) Check if the sender of a message is the same as the current user, in which case we skip messages coming from Pusher.
(2) Before sending msg data to Pusher, we copy-paste the html onto the message thread.
That's not really "writing code", as far as thousands of lines of code are concerned.
I was first introduced to this concept by Discourse, where the frontend immediately puts into effect whatever you want to do - whether it's deleting or editing a post, and then using a callback if an error occurs. For precisely the same reasons you state, it feels faster but still gives you the option to backtrack if things go wrong.
I dont think 300ms (you did mean .3 S right)is an average page load time - hell at my last gig the target was getting 90% of pages to load in < 3 seconds.
Ok that was large publisher with some truly crufty platforms but sill sub 1s page loads are probably the exception.
I've noticed a lot of 'modern' sites now have a long-tail loading period as all the JS, resources, and real content show up.
The nav bar and structure of the FB news feed shows up < 1s for me right now, but the actual contents of the page take another few seconds. Total 3 – 5 seconds for the browser to indicate it's fully loaded.
That's correct, and doesn't that <1s load for navbar make you feel so good? Honestly, would you log into FB as often, if the first part of the page took 3 second to load?
I've talked to some friends who work at FB and yeah, they use a lot of sequential loading (forgot the technical term for that). I wish I could implement more as well; someday.
sigh...