5 ms·

Nice idea, definately not new. There is one major problem with this approach - you save document, request processing, you navigate away from page, start new wor

by zv 15y ago

Nice idea, definately not new. There is one major problem with this approach - you save document, request processing, you navigate away from page, start new work, after 30 secs your request failed. Now the code complexity for you to handle this situation is high. Multithreaded/asynchronous systems are always hard.

phzbOx 15y ago
The author specifically talks about that in the article saying that you can catch "leaving a page" and notify the user that there's still something pending and data would be lost. 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?
- gurraman 15y ago
  Does it also prevent the browser from crashing if there's still something pending? :)
  - phzbOx 15y ago
    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.
roc 15y ago
A lot of data entry is hard to unwind and correct in those kinds of situations; where a multi-step process is fully filled out and submitted based on key initial data that's later found to be wrong/invalid. But I find that you often wind up having to write code to deal with that anyway, to handle cases of inadvertent user errors. (e.g. I reserved a flight, room and rental car in Kansas City, KS -- but I was supposed to be reserving a flight, room and rental car in Kansas City, MO.) So while I'm intimately familiar with and sympathetic to the challenge and complexity involved; I don't know that it's additional challenge or complexity.
tacoe 15y ago
http://www.d-e-f-i-n-i-t-e-l-y.com/ http://www.d-e-f-i-n-i-t-e-l-y.com/

by zv 15y ago

phzbOx 15y ago

The author specifically talks about that in the article saying that you can catch "leaving a page" and notify the user that there's still something pending and data would be lost. 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?

gurraman 15y ago
Does it also prevent the browser from crashing if there's still something pending? :)
- phzbOx 15y ago
  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.

roc 15y ago

A lot of data entry is hard to unwind and correct in those kinds of situations; where a multi-step process is fully filled out and submitted based on key initial data that's later found to be wrong/invalid. But I find that you often wind up having to write code to deal with that anyway, to handle cases of inadvertent user errors. (e.g. I reserved a flight, room and rental car in Kansas City, KS -- but I was supposed to be reserving a flight, room and rental car in Kansas City, MO.) So while I'm intimately familiar with and sympathetic to the challenge and complexity involved; I don't know that it's additional challenge or complexity.

tacoe 15y ago

http://www.d-e-f-i-n-i-t-e-l-y.com/ http://www.d-e-f-i-n-i-t-e-l-y.com/