Add support for requestIdleCallback

[Rycochet]

https://w3c.github.io/requestidlecallback/

Looks like this can mostly be done simply by using setTimeout code, and seems quite simple to polyfill (if I get the time I'll create a PR).

Currently only Safari is missing this entirely.

[zloirock]

I'm not sure that it's in the scope of core-js. I'll think about it.

[icy0307]

What is the 'scope' of core-js? According to the homepage,

Modular standard library for JavaScript. Includes polyfills for ECMAScript up to 2023: promises, symbols, collections, iterators, typed arrays, many other features, ECMAScript proposals, some cross-platform WHATWG / W3C features and proposals like URL.

Isn't requestIdleCallback already part of w3c features?
We are using babel-loader + core-js with useBuiltIns: usage. So our project is depend on browserlist, and the polyfill is added according to code, everything is on demand.
But core-js doesn't support requestidlecallback, we have to add an ugly polyfill in our entry.
Is there any other way we could do to avoid this? @zloirock

[zloirock]

"Some cross-platform WHATWG / W3C features" it's not all W3C features.

I don't think that requestIdleCallback is a closely related to JS web platform feature, the primary target for core-js in the scope of web standards is the Minimum Common Web Platform API, however requestIdleCallback makes sense in the scope of core-js too.

The extended support of the web platform features in core-js is a great challenge that requires significant resources that core-js still have not.

If you need something like this now, you could try core-web.

[icy0307]

Thanks for being a big help. @zloirock
Just for clarity, is it ok to tell my team we can just use core-js for everything related to Minimum Common Web Platform API or requestIdleCallback?
that we should make a pull request when something is absent. (Can we make a pull request about requestIdleCallback right now?)
And as for everything not in Minimum Common Web Platform API, like resizeobserver we should find our own way to make it work with babel toolchains?

I can't help wondering why core-js have this scope boundary. As long as the way we implement it is "pure", the global scope won't be polluted, and the bundle size won't be bloated. What is concerning you?
It seems like core-web is not quiet supported by the community like core-js does. Why can't core-js just implement every cross-platform WHATWG / W3C features as long as it is possible?

[zloirock]

Just for clarity, is it ok to tell my team we can just use core-js for everything related to Minimum Common Web Platform API or requestIdleCallback?

In the future when it will be implemented.

We should make a pull request when something is absent. (Can we make a pull request about requestIdleCallback right now?)

Why not? I added a help wanted label -)

And as for everything not in Minimum Common Web Platform API, like resizeobserver we should find our own way to make it work with babel toolchains?

See this issue. The Minimum Common Web Platform API is just the current priority, after that maybe will be added the rest.

I can't help wondering why core-js have this scope boundary. ... Why can't core-js just implement every cross-platform WHATWG / W3C features as long as it is possible?

The first issue - I just haven't enough resources, at first - time and money - I already ensure compatibility for most of the popular internet websites (it's a naive detection - you could add some more dozen of percents) alone almost full time for 5$ / hour from donations and I should somehow feed my family.

Polyfills should not be naive. Now the correctness of ECMAScript features almost everywhere is not very bad, but I can't say it about web platform features. For example, recently was added a structuredClone polyfill. During work on it, I faced hundreds of different JavaScript engines bugs - I don't remember when I saw something like that when I added new ECMAScript features - for this reason, the work on this simple method, that naively could be implemented for a couple of hours, with resolving all issues and adding required features, lasted for several months. Better to do nothing than to do bad, the proper testing, polyfilling and ensuring cross-platform compatibility web platform features require even more significant resources than that I spend on ECMAScript polyfills. So adding maximum possible web standards support to core-js will be started only in case I will have such resources.

The second issue is size. The size of core-js is constantly growing because of adding new or improving existing polyfills. Adding Intl, Temporal, and some other features to core-js could increase the maximal bundle size a dozen times to some megabytes. It should be solved (and now partially solved) on the tooling side - but it's another big discussion.

I hope that in the near future I will describe in detail the current problems and priorities.