Is there anything inherently wrong with using setTimeout to simulate a parallel action?

Question

When the users of this app make changes to the fields a large amount of changes need to happen across other fields. Typically even with optimized scripts the browser will block user input for upwards of 1 second in IE. To stop with from occurring I do this:

var i = 100;
GetTextInputs().filter('[' + name + ']').each(function()
{    
    setTimeout("DoWork('" + this.id + "', '" + v + "', '" + name + "');", i);
    i += 25;
});

It feels kind of hackish to me but works great.

• Can anything go wrong with this method?
• Alternatively, is there a better way?

Answer 1

Right now, I don't think you've got much of a choice, actually.

I've not checked if your function was working, but using setTimeout and splitting the work in small chunks is probably the way to go.

In the future, though, you might use Web Workers, for that ; quoting from Mozilla's webpage :

Workers provide a simple means for web content to run scripts in background threads. Once created, a worker can send messages to the spawning task by posting messages to an event handler specified by the creator.

The worker thread can perform tasks without interfering with the user interface. In addition, they can perform I/O using XMLHttpRequest (although the responseXML and channel attributes are always null).

And :

One way workers are useful is to allow your code to perform processor-intensive calculations without blocking the user interface thread.

Those are already available in Firefox 3.5, and I think they are provided by Google Gears too -- but they are not widely available yet, so you probably shouldn't use them before a couple of years, at least for an application used by "anyone" :-(

Answer 2

In order to have a better user experience I use setTimeout a great deal, so that as much as possible work can happen more in the background.

It is similar in windows to having everything run on the main event thread. It is more work to get the application off that thread, but ultimately the user will have a better experience.

The only things that may go wrong is that if you have a variable change before it is actually used in the setTimeout then the action may be different.

So you may to at least be aware of that if you see some odd behavior. Ideally your design shouldn't allow it, but it could happen.

Answer 3

One thing that can go horribly wrong is that having too many high-frequency timers can [ironically] make the ui sluggish/unresponsive. From http://googlecode.blogspot.com/2009/07/gmail-for-mobile-html5-series-using.html:

With low-frequency timers — timers with a delay of one second or more — we could create many timers without significantly degrading performance on either device. Even with 100 timers scheduled, our app was not noticeably less responsive. With high-frequency timers, however, the story was exactly the opposite. A few timers firing every 100-200 ms was sufficient to make our UI feel sluggish.