Remove second arg from setTimeout calls (WAS jQuery.later)

[gnarf]

We are starting to use more and more setTimeout( fn, 0 ); calls around our code base. I think now that there is also a setImmediate and there is also the postMessage that we should probably try to take advantage of these.

I would like to propose a jQuery.later( fn ) that wraps the "best" possible function here.

[Rick Waldron]

neat!

[sindresorhus]

#10936 is a duplicate of this ticket.

[jzaefferer]

-1, There is no reason why this needs to depend on jQuery apart from bundling it.

[jaubourg]

+1, not only does it make sense, it should also save some size.

[dmethvin]

+1, It's small and we can use it internally, so yeah.

[mikesherov]

+1, mostly fluff, but honestly, I'm personally sick of setTimeout( fn, 0). Let's do it.

[Rick Waldron]

+1, Seems highly useful

[Timmy Willison]

-1, I don't think it's worth it

[hkdobrev@…]

+1

It should save size and it would really prevent jQuery users from bad usage of setTimeout. For example many developers still do things like:

setTimeout("a lot of javascript in a string", ...)

[gibson042]

I like the standardization and size neutrality (jquery.js has 5 instances of setTimeout( fn, 0..1 ), making this cost at most 12 bytes minified). But how about calling it jQuery.soon?

[Timmy Willison]

I'll elaborate. I don't think this will give us the benefit we're looking for. In terms of performance, adding the function call will likely negate the benefit of using postMessage. The best performance always has the smallest stack. Besides, we're talking ops in the millions if comparing postMessage to setTimeout. As for setImmediate, it is not currently implemented in any browser except IE and will probably never become part of the spec. IE10 will implement it as msSetImmediate. I definitely don't think we should make use of that yet.

It is my understanding that the overall direction for browser vendors is to optimize for setTimeout(fn, 0) rather than add another function. We could very well be forcing the jQuery API to go in a direction we will regret later. I'm not saying never, but I suggest we table it.

[gnarf]

Even if it doesn't wrap any other method, just having it wrap setTimeout( fn , 0 ) is nice

[dmethvin]

We haven't done this yet in 1.8, but I'm also not seeing any place where it is going to save us anything in the current code. Thoughts? Should we push to 1.9 and discuss then?

[dmethvin]

Thoughts about the benefits? The setTimeout implementation adds a relatively large delay but is not a lot of code. I'm on the fence about it now.

[gibson042]

I'm neutral on this too, but +1 if it reduces size.

[mikesherov]

+1, I'm with @gibson042 on this. If it's smaller, sure.

[Rick Waldron]

+1, But we need to bikeshed on the naming

[gibson042]

+1, if it reduces size

[anonymous]

+1

[Oleg]

Fix #10417. setTimeout w/o 2nd arg is jQuery.later! Close gh-1065.

Changeset: d41b983259042d3a07ae785c09f71c68d9ce7c3f