Forums

Earlier this year I was looking for a fun project to do and I began researching the implementation of promises and deferreds. My research lead me to the CommonJs Promises/B proposal which requires that all callbacks be called in a future turn of the JavaScript event loop, they must be asynchronous. It also lead me to the q API which implements a simple polyfill around setImmediate.

At that point I had used process.nextTick in Node.js but I hadn't heard of setImmediate. These things are a way to tell the JavaScript interpreter to run a function asynchronously. The result is very similar to setTimout or Y.later, except you don't pass it a number of milliseconds to wait. There are no timers involved. The JavaScript interpreter adds the function call to the event loop in the most efficient way possible.

Why is this important? Isn't setTimeout(0, fn) good enough? The bad thing about setTimeout is that when you pass a low value, it ignores you. There is a minimum number of milliseconds that it will use. There are other negative effects when using very short duration timers. Here's the spec and some articles:
https://dvcs.w3.org/hg/webperf/raw-file ... rview.html
http://ie.microsoft.com/testdrive/Perfo ... fault.html
http://www.nczonline.net/blog/2011/09/1 ... immediate/

Node.js has a similar feature called process.nextTick. It describes it as 'much more efficient'.
http://nodejs.org/api/process.html#proc ... k_callback

Unfortunately, setImmediate is not implemented in most (or any) current browsers. Luckily, there are other features in JavaScript interpreters which execute functions asynchronously without the use of timers. There are many polyfill implementations of setImmediate. They use clever hacks built around these other features to achieve the same effect. I picked my favorite, most cleverest polyfill and rewrote it for YUI and it became gallery-soon.

Y.soon is the public interface I made. It accepts a single argument, the callback function. It returns an object with a cancel method just like Y.later. The polyfill in gallery-soon contains six different implementations of Y.soon. It is pretty quick: http://jsperf.com/y-soon-vs-settimeout

One design decision I made that I'm sure will be questioned: I don't use Y.bind, accept a context object, or arguments. I found that in my own code, I was usually using closure variables and had no need for a bound context. I decided that the overhead it costs wasn't worth it. Developers can easily Y.bind callbacks themselves when necessary.

Eventually I abandoned my work on promises in favor of qr-codes. Recently, Luke Smith has implemented deferreds and promises and has submitted a pull request to YUI. I suggested Y.soon for use within his promises implementation; that is in fact the exact reason I originally made it. His pull request contains a check for the existence of Y.soon and falls back to setTimeout. The question has been brought up as to whether gallery-soon should be promoted to YUI core. There are several very good arguments both in favor of and against.

I'll offer my opinion and if there is a sense of agreement here, I'll work on a pull request.

I don't think gallery-soon as it is should be pulled into core. Others have already pointed out that it's a huge hack and there are concerns for unit testing and cross browser maintainability. I am aware of several potential risks in the code that could break things or cause security vulnerabilities. I don't think these risks are high (they might not even exist) but they haven't been thoroughly investigated. I've personally been using gallery-soon in a number of projects without any issue, and I'll encourage everyone to use it, but that alone doesn't mean it meets the code quality expectations of a YUI release. This doesn't mean it will never happen; someone would need to take the time to explore the large number of edge cases, write tests, documentation, etc.

I do think Y.soon should be pulled into core. I propose the following:

A new YUI core module called 'soon'. It would have two implementations of Y.soon interface and use conditional loading to pull the correct one. In Node.js it would be a YUI friendly wrapper around process.nextTick. In all browsers, it would be a shortcut for Y.later(0, null, fn); This would be a helpful API normalization over these environments. Once browsers start implementing it, a YUI friendly wrapper around setImmediate should be added as well. Those two or three implementations should be easy enough to write tests for and maintain. There is little to no hacking involved.

I would like to separate the gallery module into a number of smaller modules. Once 'soon' is a core module, developers could just use it or decide for themselves if they would like to replace it with 'gallery-soon-postmessage' or 'gallery-soon-readystatechange' and set up their own conditional loading strategy. It will also make it easier for other developers to invent their own crazy implementations.

Eric,

Thanks! I spent a while debating with myself but eventually agreed with all of your points.

I'll get started on this in the coming weeks as my schedule allows.

So thinking about this more, I think there's another aspect that should be considered.

There can be cases where we want code to execute async, but before the next DOM repaint. Using `setTimeout()`, we'll be forced to wait for the next repaint. Therefore I think we might want to consider using one of the hacks for non-IE browsers (assuming that `setImmediate()` will call the callback before the next repaint.)