search

zloirock / core-js

Standard Library
MIT License
23.99k stars 1.62k forks source link

What ancient engines should be supported? #1301

Closed zloirock closed 5 months ago

zloirock commented 6 months ago

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?

Let's take a look at other engines:

What does it mean?

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 commented 6 months ago

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

ehoogeveen-medweb commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

@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.

2023-11-13_22-50-03

erikt9 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

I mean specific statistics, references, and links.

gnh1201 commented 6 months ago

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 commented 6 months ago

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

gnh1201 commented 6 months ago

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

zloirock commented 6 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

I'm taking this to work. You can follow the changes here: https://github.com/zloirock/core-js/pull/1310