What ancient engines should be supported?

[zloirock]

Now there is active work on core-js@4.

One of the decisions that will be realized in core-js@4 and made quite a long time ago is the refusal to support engines without basic ES5 support (for example, IE8-). This will not reduce the full library size significantly (maybe only about 3-4%), it will not significantly reduce the number of modules (only some modules and polyfills only of some features will be removed - too many of them were changed in future ES versions or have bugs), however, it will allow significantly untangle core-js and reduce the size of minimalistic core-js bundles that contain only some modules by several times.

As an option, it could be good to bump the lower bar a little above basic ES5 support with similar result. Let's discuss it.

IE11 support is still a strict requirement for some core-js users, but not IE9 / IE10.

What IE11 could give us in case of dropping IE9 / IE10 support?

• Basic WeakMap support. That requires patching for modern semantics and fixes many bugs in polyfill. However, that can be used in core-js internals and significantly simplify them. It's the main one that we could get. Without it, the rest doesn't matter much.
• Basic Map and Set support. That requires full replacement in polyfill. However, that can be used in some internal core-js cases.
• A way setting of prototype - Object.setPrototypeOf or __proto__. That could simplify some minor internal core-js cases.
• Basic support of %TypedArray% constructors, ArrayBuffer, DataView could help to untangle %TypedArray%-related features and significantly reduce their size.
• The strict mode that was missed in IE9 does not have a principal meaning for core-js code.

---

Let's take a look at other engines:

• Basic WeakMap support added in Chrome 36, Safari 7.1, FF6
• Basic Map and Set support added in Chrome 38, Safari 7.1, FF13
• A way setting of prototype - Object.setPrototypeOf or __proto__ - in all quite popular engines >= IE11
• Basic support of %TypedArray% constructors, ArrayBuffer and DataView added in Chrome 5, Safari 5.1, FF15

What does it mean?

• Setting the lower bar to something like IE11, Chrome 38, Safari 7.1, FF15, Node 0.11.15 and the like
• End of ancient Android (4.4.3 ~ Chrome 36) support (maybe the most critical case)
• End of PhantomJS (~ IIRC Safari 6.0) support (sadly since it's useful for testing compatibility with old engines on CI)
• End of Duktape support (Invalid global object detected when bundling with esbuild and running on Duktape #1303 (comment))
• End of Opera Presto (12-) support (anyway I don't see any users of this engine in the stats)
• Rising the bar higher makes no sense because of IE11 limitations

It could be slightly tweaked. For example, we could avoid native Map / Set and leave Chrome 36 -> Android 4.4.3 support.

In addition, it will allow us to drop painful workarounds for a dozen bugs of those engines.

What do you think?

[zloirock]

So, no one wants to speak out on such a fundamental point?

[ehoogeveen-medweb]

I wonder how many people have seen this discussion. Perhaps it would be helpful if there were some news articles about it or if you could reach out to users in some other way (note: I don't have any contacts).

Personally, our (small) company does not rely on even IE11 support anymore, we just need to target browsers from a couple of years ago - therefore I would be fine with raising the minimum requirement.

[zloirock]

I wonder how many people have seen this discussion.

Some hundreds of the repo followers, some hundreds of accidental visitors, and a couple of dozen potentially interested people to whom I sent this link.

Perhaps it would be helpful if there were some news articles about it

I'm not sure that required a new separate small post about it. My previous couple of posts contain this subject, see the link at the top of this thread. The related parts were focused on pre-ES5 (IE8-), however, mentioned this too. Here are only clarifications. Those posts had millions of views and it seems a dozen thousand users had read those parts - but I hadn't any significant feedback about this subject (however, all feedback about it that I had was positive).

Personally, our (small) company does not rely on even IE11 support anymore, we just need to target browsers from a couple of years ago - therefore I would be fine with raising the minimum requirement.

Thanks 👍

[Sharktheone]

I'd say, Android 4.4.3 is the most critical because you can't upgrade your Android version most of the time. I don't know, if you can upgrade your chrome version, from your comment I assume it is not possible since you spoke about Android and not a specific Android webview or something. From my experience, people with low requirements often keep their devices/phones long. I also know someone that uses a very old phone with maybe Android 4 or something. Even tough a 10 year old Android version / phone might be ancient for you and most other people that you will meet here, it might not be so for people with lower expertise in tech. I think, dropping hardware support (when you can't upgrade your chrome / android version) it might not be the best.

I have no particular opinion to this, but I just want to mention this here.

[zloirock]

@Sharktheone yes, you are right - Android is the most critical case here, I mentioned it by the link above. However, I see that the share of 10+ year-old Android has dropped significantly for some previous months.

[erikt9]

Proposals in first post are good for us. Currently targeting IE 11 as the floor with our babel, so having IE 11 as the floor in core-js works. Thanks for all your hard work!

[gnh1201]

If support for IE is discontinued, it cannot be ignored that it may impact standalone ECMAScript engines supporting a level similar to PRE-ES5 like IE, like IE8(-).

Discontinuing IE support may raise concerns about the cessation of support for similar standalone engines at a comparable level. I have referenced cases from energy-related companies in Korea, Russia, France, and Japan during a project related to this. They indeed use PRE-ES5 engines for "industrial" purposes.

[zloirock]

@gnh1201 could you explain it in details? Could you show those references and statistics? What do you mean by "PRE-ES5, like IE"? Pre-ES5 is only IE8-. IE11 is planned to support even with changes discussed here.

[gnh1201]

I've been observing the work of Russian friends proficient in PRE-ES5 syntax for quite some time. There was even an incident in the United States that made it to the news due to their involvement.

Despite others mocking them as hackers using outdated technology, I recognized their remarkable skills and decided to learn from them. In their projects, I found a lot of code applicable to Factory Automation (FA), and I discovered real-world cases spanning various countries.

I, too, interpreted their techniques, and for a while, worked for relevant companies, earning a salary based on these skills.

[zloirock]

I mean specific statistics, references, and links.

[gnh1201]

Unfortunately, there are no specific statistics available, but I'm providing a link to an incident that solidified my conviction about the existence of Industrial ECMAScript: Colonial Pipeline Ransomware Attack.

Thanks to this incident, I was able to advance my research on Industrial ECMAScript, and I could also apply it to the company I was working for.

[zloirock]

Sorry, but I still don't see how it's related to this thread.

[gnh1201]

If I've been too talkative or said anything unnecessary, I apologize. core-js has been very helpful to me. Thank you! :)

[zloirock]

Hey, I just don't understand what you mean. I know about cases that you mentioned definitely more than most people, but anyway can't understand how it's related to this thread.

Yes, ancient IE versions are still used in some specific cases, but it's a minimum cases. For even significantly fewer cases, using new versions of polyfills makes sense. From a security point of view, the use of such ancient engines with known vulnerabilities is a much greater security threat than the cessation of their support in new releases of some libraries.

For me, is not a big problem to maintain even IE5 - but it's significant unnecessary extra overhead for 99.9%+ users.

This thread is not related pre-ES5 like IE8-, it was discussed and decided a long time ago, it's related ES5+ engines like IE9 / IE10 and similar.

[qiulang]

I was wondering why you still want to support IE 11 in core-js@4? If people want to use IE 11 can't they just stick with core-js@3 ?

[zloirock]

A significant part of core-js users still need IE11 support. I don't want to leave this part of users on the old (after some time - unsupported) version. It's a fundamental moment, IE11 support will be in core-js@4.

[Sharktheone]

I am generally a friend of having things configurable. In this case, it would mean, there is one "version" / sub-module that is built for newer versions and "normal" sites can use that to reduce overhead. And projects that really need IE5 support can use this sub-module. But here I'm not sure if this is the right path. I mean, it's more effort for you and developers upgrading their core-js version also need to know about that.

I think, you already do enough, so adding even more complexity/work might not be the best. But I just wanted to raise this idea.

Also, thanks for your incredible work and basically holding large chunks of the internet together! ❤️

[zloirock]

@Sharktheone at this moment, core-js works on a similar principle - many modules have implicit dependencies that are declared in entries, but can be removed by Babel or SWC for optimization - however, not everything can be optimized by this way and support old engines cause significant overhead for users.

I experimented with the approach you propose, with multiple versions for different baselines. It is not enough to simply remove unnecessary dependencies and dead code blocks with an optimizer - everything is much more complicated, which will lead to multiple increases in the time required for maintenance and other problems - which, in my opinion, is not worth it.

[Sharktheone]

everything is much more complicated, which will lead to multiple increases in the time required for maintenance and other problems - which, in my opinion, is not worth it.

Yup, that's what I thought. I just wanted to raise this idea.

[zloirock]

I'm taking this to work. You can follow the changes here: #1310