Requests for features that fall outside of `es`

[romainmenke]

There are often feature requests here for non-es features.

We found that having those polyfills in core-js can be a challenge.

DOM iterators for example requires polyfills for DOM collections for browsers without native support.

The polyfill for a DOM collection might depend on newer language features.

1. polyfill language features (core-js)
2. polyfill web features
3. polyfill specific features after web (core-js: web.dom-collections.iterator)

This very specific execution order makes it hard to configure everything correctly.

Is there something that could be done to improve this?
Or might it be better to avoid non-es features?

This is something we solved for ourselves with core-web and we found a relatively low effort way to avoid conflicts or incorrect loading orders.

But we fear that having more and more dom features here will make core-js harder to use and maintain.

[zloirock]

Hi @romainmenke, sorry for the delay with reply.

A simple answer is - core-js should not avoid non-ES features. One project that solves all polyfilling issues could significantly simplify the life of users. The web platform architecture is terrible and very tangled - for example, why structuredClone defined in the HTML spec instead of ES where it should be placed logically?

I agree that having those polyfills in core-js is a challenge, however, we should handle this challenge.

core-web is a great project with a great purpose, but since it uses polyfills from polyfill-service I'm considering it as a temporal solution. In my vision, the most of polyfills from polyfill-service are too naive - not enough correct and strict.

At this moment and for the next few months, I don't think that something excepting iterable DOM collections will cause such problems for you.

Is there something that could be done to improve this?

Sure, I always welcome contributions - you could find some issues about the implementation of web standards, you could improve something existent.

I think that a little bit later I'll give a little more detailed answer.

[romainmenke]

Hey @zloirock, thank you for getting back to me on this.

A simple answer is - core-js should not avoid non-ES features. One project that solves all polyfilling issues could significantly simplify the life of users.

This is already great to hear as it wasn't fully clear to me what your position was on this.

One project that solves all polyfilling issues could significantly simplify the life of users.

core-web is a great project with a great purpose, but since it uses polyfills from polyfill-service I'm considering it as a temporal solution.

I agree, core-web exists because our frontend team kept adding both polyfill.io and core-js to all projects, often missing polyfills and having duplicates at the same time.

This issue is not unique to us and illustrates how difficult it is to get this right in the current landscape.

If there is a place for "web" feature polyfills in core-js that would be the best in the long term.

[romainmenke]

Going to close this as I mainly wanted to know your position and hear your thoughts!
I am currently swamped with work on other projects but I will keep this in mind going forward.

would be really nice if there was only one tool for polyfills without need for things like core-web

[zloirock]

Let's reopen it to avoid some questions.