As you can see from printed console.log statement that whole load of setInterval events arrive immediately after each other without any delay.
Didn't get a point, as I see from printed console, results are fully predicted. Every single "insideSetInterval" prints with delay of two seconds (like described in setInterval), and also - "returning from server" appears after 4 seconds since first setInterval, which was called with timeout 4000ms, where is "without any delay"?
If you speak about no delay between "returning from server" and "insideSetInterval", of course, because setTimeout with 4sec will wait until interval will be executed twice), and dont have to be in sync with interval prints. With heavy calculation it can load stack, but for simple refreshes - like a timer display update or some other light calculations - working properly, if not forget to handle instance with "clearInterval" when it's no needed anymore.
You are right, for light calculations it does not make much of a difference. But for example gmail has to refresh your inbox when new mail arrives, if we were to do it by setTimeInterval, we will queue a lot of requests at server. I have changed the contents of the blog. Please go through that maybe it will put across my point clearly.
Thanks for your reply, yes. I agree, if there will be heavy calculation or long time awaiting, it will work unpredictable. For heavy calculations I would like to use some kind of state machines, which will not make additional request if previous one still in pending state (can be timeout of it). Unfortunatelly, we cannot stop executing request to a server, but we can mark it in client side as NOT VALID (throw exception after some timeout), but this will continue execution on server and in case of non-stop requests, they will do DoS attack. But that's also not a setInterval and setTimeout case, there have to be much more code over it, to prevent that kind of issues. If server taking decision when content have to be updated - WebSockets can prevent lot of issues, IMHO they are ready to be used in production.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Didn't get a point, as I see from printed console, results are fully predicted. Every single "insideSetInterval" prints with delay of two seconds (like described in setInterval), and also - "returning from server" appears after 4 seconds since first setInterval, which was called with timeout 4000ms, where is "without any delay"?
If you speak about no delay between "returning from server" and "insideSetInterval", of course, because setTimeout with 4sec will wait until interval will be executed twice), and dont have to be in sync with interval prints. With heavy calculation it can load stack, but for simple refreshes - like a timer display update or some other light calculations - working properly, if not forget to handle instance with "clearInterval" when it's no needed anymore.
You are right, for light calculations it does not make much of a difference. But for example gmail has to refresh your inbox when new mail arrives, if we were to do it by setTimeInterval, we will queue a lot of requests at server. I have changed the contents of the blog. Please go through that maybe it will put across my point clearly.
Thanks for your reply, yes. I agree, if there will be heavy calculation or long time awaiting, it will work unpredictable. For heavy calculations I would like to use some kind of state machines, which will not make additional request if previous one still in pending state (can be timeout of it). Unfortunatelly, we cannot stop executing request to a server, but we can mark it in client side as NOT VALID (throw exception after some timeout), but this will continue execution on server and in case of non-stop requests, they will do DoS attack. But that's also not a setInterval and setTimeout case, there have to be much more code over it, to prevent that kind of issues. If server taking decision when content have to be updated - WebSockets can prevent lot of issues, IMHO they are ready to be used in production.