Optimistic UI with Meteor
info.meteor.com
info.meteor.com
> When a user pushes a button in a website or a mobile app, they don't want to wait for a request to be sent all the way to the server to calculate the new state of the screen.
http://devchat.tv/js-jabber/114-jsj-asynchronous-ui-and-non-...
The guest was talking about the difficulty of putting yourself in the shoes of someone far away from the global data-centres, when you live and work in Silicon Valley / New York / London (he's from New Zealand).
He also said (which I thought was interesting) that Amazon preloads the first items on the next search page, so the user doesn't have to wait for the server, and then loads the rest in the background (with the idea that by the time they have examined the first items, the others will have arrived).
Until now, I think Meteor wasn't on message for the experienced developer market.
It's a mistake to sell a technical product with the pitch "Look at what you can do with just a few lines of code!!!". And/ Or over simplified demos.
We want to see more articles like this- So now we know how it works - what are the limitations? What are the problems scaling? etc.
The reason is actually a common theme throughout Meteor: boilerplate code, and somewhat relatedly "devops" type code, are taken care of by the platform so you get to focus on building your app.
It's such a big focus of Meteor's design compared to every other platform, and it's what's kept me coming back for three years.
In fact, it's surprising that so few other platforms have picked up on the fact that eradicating boilerplate is a feature, and they should compete on it. Maybe with more posts like this, they'll be inspired to head in that direction!
Isn't this just lying to the user? What if the user acts on the update (e.g. closes the page, satisfied the file has been saved) and thereby loses data?
This is in contrast to a large proportion of existing patterns where the option to simultaneously pile on tasks and keep synchronicity is not available.
I think we're debating the merits of different classes of update here. Some updates are not essential (UI preferences, etc.), but other requests by their very nature, are--billing, messaging, draft editing, etc.
So we simulate the changes as the user makes the action, 'optimistic UI updating' and then wait for confirmation on the server to persist the data. During that waiting period, we tell the user that their changes are being saved, but they are free to do what ever they wish.
It lets the user know things are happening, but might not persist because we are still in the mode of saving, yet allows the user to carry on with their tasks while we deal with the information they send us.
If they close the page, during this time, they are well aware that the changes are happening. The request has been made, it just didn't return yet.
Meteor's architecture allows you to have slightly different models in the "predictive" mode and "persisted" mode.
Getting a good prediction and then knowing how to gracefully reconcile a missed prediction is part art, part science and what makes building those systems a ton of fun.