Re:Asynchronous UIs - the future of web user interfaces
by gurraman on Wednesday November 16, 2011 @02:58PM
(#3244797)
Does it also prevent the browser from crashing if there's still something pending? :)
Re:Asynchronous UIs - the future of web user interfaces
by phzbOx on Wednesday November 16, 2011 @05:41PM
(#3245457)
No, but that's not the point. If the web page is telling you "Wait, your email is being sent" and you close your browser, do you expect the email to be sent? Or if it says "Please wait, the document is being saved" and you close the application..
I.e. The point is that asynchronous make it feels smoother. If the browser crashes while data is being transmitted, there's nothing you can do. Ajax, asynchronous or whatever. So, what will happens is the data will be lost. The asynchronous part doesn't resolve all problems.. it just feel faster for the user.
And, by the way, why the ":)" at the end? Is it because you were happy? Personally, I find that a bit provocative. (i.e. in gaming, people would say "You suck :)" or if they'd crush you, they would just say :). It's being bad manner.) But then, if you were happy and just wanted to show it, sorry for this comment.
And in the case of a big error, you can either refresh the page.. or clear the models and resend them in json format to stay sync with the server. It might be a little more complicated, but with a good framework, not that much more. I.e. multithreaded code is a pain.. asynchronous or not, it's a pain. And, in the rare case where you really need to wait for the server to answer back, well, use a loader. But there's a difference between using a loader when you absolutely need it, and everywhere. Think of how apps work on the desktop.. everything is lighting fast, but in some rare occasions, it blocks. What is better? Something that always block or something that sometime block?