それでは、ネガティブからこの投稿の後半に移り、実装すると便利なこととポリフィルの問題について説明します。

core-js

ロードマップ

JavaScript、ブラウザ、およびWeb開発は、驚くべきスピードで進化しています。ほとんどすべてのモジュールがすべてのブラウザに必要だった時代は終わりました。最新のブラウザは優れた標準サポートを備えており、一般的なユースケースでは、最新の言語機能とバグ修正に必要なモジュールの割合はわずかです。一部の企業は、最近再び「埋もれ」たIE11のサポートをすでに終了しています。ただし、IEがなくても、古いブラウザは常に発生し、最新のブラウザでもバグが発生し、新しい言語機能が定期的に表示され、とにかくブラウザに遅延して表示されるため、開発で最新のJSを使用し、起こりうる問題を最小限に抑えたい場合は、ポリフィルは長い間私たちと一緒にいますが、進化する必要があります。

core-js

core-js

ここでは、新しいポリフィルの追加や既存の特定のポリフィルの改善については(ほぼ)書きません(ただし、確かに、これは開発の主要な部分の1つです)、マイナーなことに焦点を当てずに、他の重要な瞬間について話しましょう。から商用プロジェクトを作成することが決定された場合、ロードマップはこの条件に適合します。

core-js

core-js

I am trying to keep as compact as possible, but one of the main conceptions that it should follow is to be maximally useful in the modern web - the client should not load any unnecessary polyfills and polyfills should be maximally compact and optimized. Currently, a maximal bundle size with early-stage proposals is about 220KB minified, 70KB gzipped - it's not a tiny package, it's big enough - it's like jQuery, LoDash, and Axios together - the reason is that the package covers almost the entire standard library of the language. The individual weight of each component is several times less than the weight of quite correct alternatives. It's possible to load only the features that you use and in minimal cases, the bundle size can be reduced to some kilobytes. When is used correctly, this is usually a couple of tens of kilobytes - however, there is something to strive for. Most pages contain pictures larger even the full bundle, most users have Internet speed in dozens of Mbps, so why is this concept so significant?

core-js

core-js

core-js

core-js

core-js

I don't want to repeat old posts about the cost of JavaScript in detail where you can read why adding JS increases the time when the user can start interacting with the page much more than adding a similar size picture - it's not only downloading, it's also parsing, compiling, evaluating the script, it blocks the page rendering.

In too many places, mobile Internet is not perfect and still 3G or even 2G. In the case of 3G, downloading of one full copy of can take a couple of seconds. However, pages contain more than one copy of and many other duplicated polyfills too often. Some (mainly mobile) Internet providers have very limited "unlimited" tariff plans and after some gigabytes reduce the speed to some Kbps. Internet speed is also often limited for many other reasons.

core-js

core-js

The speed of the page loading equals the revenue.

Illustration is from a random post by googling

The size of is constantly growing because of adding new or improving existing polyfills. This issue also is a block for adding some big polyfills - adding , , and some other features to could increase the maximal bundle size a dozen times to some megabytes.

core-js

Intl

Temporal

core-js

One of the main killer features is that it can be optimized with the usage of Babel, SWC, or manually, however, current approaches solve only a part of the problem. To properly solve them, the modern web requires a new generation of the toolkit that could be simply integrated into the current development stack. And in some cases, as you will see below, this toolkit could help to make the size of your website pages even less than just without .

core-js

core-js

I already wrote about some of this in

core-js@3

Since the future of the project is in doubt, it makes no sense to write any specific dates here, I do not promise that all of this will be done shortly, but this is what should be strived for.

New major version

core-js@3

At this moment, about 25% of downloads are critically obsolete . Many users wanna update it to , but because their dependencies use they still use the obsolete version for avoiding multiple copies (I saw such issues on GitHub in too many projects). Too frequent major updates would worsen such cases even more.

core-js

core-js@2

core-js@3

core-js@2

However, it's better not to get too obsessed with compatibility with older versions. The library contains too much that's not removed only for compatibility reasons. The absence of some long-needed breaking changes for someone will negatively affect the future. Judging by how the standards, the ecosystem, and the Web change, and how legacy accumulates, it's better to release a new major version each 2-3 years.

Adding all the new things that we would like to see in the new major version would take many years, which is unacceptable. However, follows SemVer and makes sense to release a new major release at first with breaking changes (some of them below), most of the new features can be added in minor releases. In this case, such a release can take just about 2-3 months of full-time work and it can be the first version that reduced the size compared to the previous -)

core-js

core-js

core-js

package directly

Drop critically obsolete engines support

IE is dead. However, not for all - for many different reasons, someone is still forced to make or maintain websites that should work in IE. is one of the main tools that makes life easier for them.

core-js

At this moment, tries to support all possible engines and platforms, even ES3 - IE8-. But only a small part of developers using needs support of ES3 engines - at this moment, the IE8- segment of browsers is about 0.1%. For many other users, it causes problems - bigger bundle size and slower runtime execution.

core-js

core-js

The main problem comes from supporting ES3 engines: most modern ES features are based on ES5 features, which aren't available in those old engines. Some features (like getters / setters) can't be polyfilled, so some polyfills (like typed arrays) can't work in IE8- complete. Some others require heavy workarounds. In case you need to polyfill only some simple features, the main part of size in the bundle is the implementation of ES5 methods (in the case of polyfilling a lot of features, it's only some percent, so this problem is related mainly to minimalistic bundles).

core-js

Even simple replacing internal fallbacks of ES5 features to implementations to direct usage of those native features reduces minimalistic bundle size 2+ times. After reworking the architecture, it will be reduced even more.

core-js

The IE9-10 segment of browsers already is also small - at this moment, the same 0.1%. But it makes no sense to consider dropping their support without dropping support of some other obsolete engines with similar or even greater restrictions, for example, Android 4.4.4 - in total, it's about 1%. Raising the lower bar higher than ES5 is a more difficult decision at least because of some non-browser engines. However, even dropping IE11 support in the future will not give so many benefits as dropping IE8- support now.

ECMAScript modules and modern syntax

At this moment, uses CommonJS modules. For a long time, it was the most popular JavaScript modules format, but now ECMAScript provides its own modules format and it's already very popular and supported almost everywhere. For example, Deno, like browsers, doesn’t support CommonJS, but supports ES modules. should get an ECMAScript modules version in the near future. But, for example, on NodeJS, ECMAScript modules are supported only in the modern versions - but on NodeJS should work without transpiling / bundling even in ancient versions, Electron still does not support it, etc., so it's problematically to get rid of the CommonJS version immediately.

core-js

core-js

core-js

The situation with the rest of modern syntax is not so obvious. At this moment, uses ES3 syntax. Initially, it was for maximal optimization since anyway it should be pre-transpiled to old syntax. But it was only initially. Now, just can't be properly transpiled in userland and should be ignored in transpiler configs. Why? Let's take a look, for example, at Babel transforms:

core-js

core-js

• A big part of transforms rely on modern built-ins, for example, transforms which use protocol - but , iterators, and all other related built-ins are implemented in and absent before loading.

  @@iterator

  Symbol.iterator

  core-js

  core-js

• Another problem is transpiling with transforms that inject polyfills. Obviously, we can't inject polyfills into the place where they are implemented since it is circular dependencies.

  core-js

  core-js

• Some other transforms applied on just break its internals - for example, the

  typeof

  transform (that should help to work with polyfilled symbols) breaks the polyfill.

  core-js

  Symbol

However, the usage of modern syntax in polyfills code could significantly improve the readability of the source code, reduce the size and in some cases improve performance if polyfill is bundled for a modern engine, so it's time to think about rewriting to modern syntax, making it transpilable by getting around those problems and publishing versions with different syntax for different use cases.

core-js

Web standards polyfills

I'm thinking about adding the maximum possible web standards (not only ECMAScript and closely related features) support to for a long time. First - about the remaining features from the Minimum Common Web Platform API (what is it?), but not only about them. It could be good to have one bulletproof polyfills project for all possible web development cases, not only for ECMAScript. At the moment, the situation with the support of web standards in browsers is much worse than with the support of modern ECMAScript features.

core-js

One of the barriers preventing the addition of web standards polyfills to was significantly increasing bundles size, but I think that with current technics of loading only required polyfills and technics which you could see below, we could add polyfills of web standards to .

core-js

core-js

But the main problem is that it should not be naive polyfills. As I wrote above, now the correctness of ECMAScript features almost everywhere is not very bad, but we can't say it about web platform features. For example, a

structuredClone

core-js

New approaches to tooling are more interesting

Someone will ask why it's here. What do tools, like transpilers, have to do with the project? is just a polyfill, and those tools are written and maintained by other people. Once I also thought that it is enough to write a great project with a good API, explain its possibilities, and when it becomes popular, it will acquire an ecosystem with proper third-party tools. However, over the years, I realized that this will not happen if you do not do, or at least not control, it yourself.

core-js

core-js

For example, for many years, instance methods were not able to be polyfilled through Babel , but I explained how to do it too many times. Polyfilling via was not able to be used in real-life projects because of incomplete detection of required polyfills and a bad source of compatibility data, which I explained from the beginning. Because of such problems, I was forced to almost completely rewrite those tools in 2018-2019, for the

core-js@3

runtime

preset-env

I am sure that if the approaches below are not implemented in the scope of , they will not be properly implemented at all.

core-js

For avoiding some questions related to the following text: tools will be moved to scoped packages - tools like and will become and respectively.

core-js

core-js-builder

core-js-compat

@core-js/builder

@core-js/compat

Not only Babel: plugins for transpilers and module bundlers

At this moment, some users are forced to use Babel only due to the need to automatically inject / optimize required polyfills. At this moment, Babel's

preset-env

runtime

core-js

Babel is only one of many transpilers. TypeScript is another popular option. Other transpilers are gaining popularity now, for example, SWC (that already contains a tool for automatic polyfilling /

core-js

esbuild

webpack

One of the main problems with statical analysis-based automatic polyfilling on the transpiler layer is that usually not all files from the bundle are transpiled - for example, dependencies. If some of your dependencies need a polyfill of a modern built-in feature, but you don't use this built-in in your userland code, this polyfill will not be added to the bundle. Unnecessary polyfills import also will not be removed from your dependencies (see below). Moving automatic polyfilling to the bundlers layer fixes this problem.

Sure, writing or using such plugins in many places is difficult compared to Babel. For example, without some extra tools now you can’t use plugins for custom transforms in TypeScript. However, there are always options and there would be a desire.

Automatic polyfilling / optimization of should be available not only in Babel. It's almost impossible to write and maintain plugins for all transpilers and bundlers in the scope of the project, but it's possible to do those things:

core-js

core-js

• Improve provided by data () and tools for integration with third-party projects, they should be comprehensive. For example, "built-in definitions" are still on Babel's side that causing problems with their reuse in other projects.

  core-js

  @core-js/compat

• Since some tools already provide integration, makes sense to help them, not only Babel.

  core-js

• Makes sense to write and maintain plugins for some significant tools in the scope of the project. What? Will see.

  core-js

Polyfills collector

One of the problems of the statical analysis-based automatic polyfilling on the files layer ( polyfilling mode of Babel ) was explained above, but it's not the only problem. Let's talk about some others.

usage

preset-env

Your dependencies could have their own dependencies and they can be incompatible with the version that you use at the root of your project, so injecting imports to your dependencies directly could cause breakage.

core-js

core-js

core-js

Projects often contain multiple entry points, multiple bundles, and, in some cases, the proper moving of all modules to one chunk can be problematic and it could cause duplication of in each bundle.

core-js

core-js

I already posted the

core-js

core-js

Some time ago this number was even more. Of course, a such number of copies and various versions of is not something typical, but a situation with some copies of is too common and you could see it on about half of the websites with , so for preventing this required a way to collect all polyfills from all entry points, bundles and dependencies of the project in one place.

core-js

core-js

core-js

Let's call a tool for this . This tool should take an entry point or a list of entry points and should use the same statical analysis that's used in , however, this tool should not transform code or inject anything, should check full dependencies trees and should return a full list of required modules. Require simple ways to integrate this into the current development stack. One of those ways can be a new polyfilling mode in plugins, let's call it - that will allow loading all collected polyfills of the application in one place and remove unnecessary (see below).

@core-js/collector

preset-env

core-js

collected

Removing unnecessary third-party polyfills

Now it's typical to see, for example, a dozen copies of polyfills with the same functionality on a website - you load only one polyfill from , but some of your dependencies load polyfills by themself - polyfill from one more copy, , , , , etc. But it's just ES6 which is already completely covered by - and available in most browsers without polyfills. Sometimes, due to this, the size of all polyfills in the bundle swells to several megabytes.

Promise

Promise

core-js

Promise

Promise

core-js

es6-promise

promise-polyfill

es6-promise-polyfill

native-promise-only

Promise

core-js

It’s not an ideal illustration for this issue, many other examples would have been better, but since above we started to talk about the Bloomberg website, let’s take a look at this site one more time. We have no access to the source code, however, we have, for example, such an awesome tool as

bundlescanner.com

As shown in the practice, since such analysis it's not a simple work, this tool detects only about half of libraries' code. However, in addition to 4.5 hundred kilobytes of , we see hundreds of kilobytes of other polyfills - many copies of , , (for the above reason, still does not polyfill it), , (it's a ponyfill and about them the next section), , etc.

core-js

es6-promise

promise-polyfill

whatwg-fetch

core-js

string.prototype.codepointat

object-assign

array-find-index

But how many polyfills were not detected? What's the size of all polyfills that this website loads? It seems a couple of megabytes. However, even for very old browsers, maximally a hundred kilobytes more than be enough... And this situation is not something unique - it's a too common problem.

Since many of those polyfills contain just a subset of functionality, in the scope of , we could collect data that will show if a module is an unnecessary third-party polyfill or not and, if this functionality is contained in , a transpiler or bundler plugin will remove the import of this module or will replace it to the import of suitable modules.

core-js

@core-js/compat

core-js

core-js

The same approach could be applied to rid dependencies from old versions.

core-js

Globalization of pure version polyfills / ponyfills

One more popular and similar issue is a duplication of polyfills from global and pure versions. The pure version of / is intended for usage in libraries code, so it's a normal situation if you use a global version of and your dependencies also load some copies of without global namespace pollution. They use different internals and it's problematic to share similar code between them.

core-js

core-js

babel-runtime

core-js

core-js

I’m thinking about resolving this issue on the transpiler or bundler plugins side similarly to the previous one (but, sure, a little more complex) - we could replace imports from the pure version with imports from the global version and remove polyfills unnecessary for the target engines.

That also could be applied to third-party ponyfills or obsolete libraries that implement something already available in the JS standard library. For example, usage of package can be replaced by , by , some methods by related modern built-in JS methods, etc.

has

Object.hasOwn

left-pad

String.prototype.padStart

lodash

Service

Loading the same polyfills, for example, in IE11, iOS Safari 14.8, and the latest Firefox is wrong - too much dead code will be loaded in modern browsers. At this moment, a popular pattern is a usage 2 bundles - for "modern" browsers that will be loaded if native modules are supported, , and for obsolete browsers which do not support native modules, (a little harder in a practice). For example, Lighthouse can detect some cases of polyfills that are not required with the target, let's check the long-suffering Bloomberg website:

<script type="module">

<script nomodule>

esmodules

Lighthouse shows just about 200KB in all resources, 0.56s. Let's remember that the site contains about a couple of megabytes of polyfills. Now Lighthouse detects less than half of the features that it should, but even with another half, it's only a little part of all loaded polyfills. Where are the rest? Are they really required for a modern browser? The problem is that the lower bar of native modules support is too low - "modern" browsers, in this case, will need most of the polyfills of stable JS features that are required for old IE, so a part of polyfills is shown in the "unused JavaScript" section that takes 6.41s, a part is not shown at all...

From the very beginning of work on , I'm thinking about creating a web service that gives only the polyfills that are needed for the requesting browser.

core-js

The availability of a such service is the only moment in which have lagged behind another project.

polyfill-service

WeakMap

WeakMap

core-js

core-js

Creating such a service in the proper form requires the creation and maintenance of many new components. I work on alone, the project does not have the necessary support from any company, and the development is carried out with pure enthusiasm, I need to look for funds to feed myself and my family, so I have no time and other resources required for that. However, in the scope of other tasks, I already made some required components, and discussions with some users convinced me that creating a maximally simplified service that you could start on your own server could be enough.

core-js

We already have the best set of polyfills, the proper compatibility data, and the builder which already could create a bundle for a target browser. Already mentioned above could be used for optimization - getting only the required subset of modules, plugins for transpilers / bundlers - for removing unnecessary polyfills. Missed a tool for the normalization of the user agent and a service that will bind those components together. Let's call it .

@core-js/collector

@core-js/service

How should it look in the perfect world?

• You bundle your project. A plugin on the bundlers side removes all polyfills import (including third-party, without global pollution, from your dependencies, etc.). Your bundles will not contain any polyfills.
• You run . When you run it, checks all your frontend codebase, all your entry points, including dependencies, and collects a list of all required polyfills.

  @core-js/service

  @core-js/collector

• A user loads a page and requests a polyfill bundle from the service. The service gives the client a bundle compiled for the target browser that contains the required subset of polyfills and uses allowed syntax.

したがって、この複雑なツールを使用すると、最新のブラウザーは、必要でない場合、ポリフィルをまったくロードせず、古いブラウザーは、必要で最大限に最適化されたポリフィルのみをロードします。

上記のほとんどは、クライアントに送信されるポリフィルのサイズを最小限に抑えることですが、これらはスコープで実装するのが良い概念のほんの一部ですが、それでも膨大な作業が必要であり、この作業はWeb開発を大幅に改善できることを理解するのに十分だと思います。それが実際に実装されるかどうか、そしてそれがFOSSとして利用可能になるか商用プロジェクトとして利用可能になるかはあなた次第です。

core-js

結論

これは、適切な品質と機能レベルを備えた無料のオープンソースプロジェクトとして維持する最後の試みでした。これは、オープンソースの反対側に実在の人々がいて、家族を養う必要があり、解決すべき問題があることを伝える最後の試みでした。

core-js

あなたまたはあなたの会社が何らかの方法で使用し、サプライチェーンの品質に関心がある場合は、プロジェクトをサポートしてください。

core-js

• オープンコレクティブ
• パトレオン
• ブースティ
• ビットコイン ( bc1qlea7544qtsmj2rayg0lthvza9fau63ux0fstcz )
• アリペイ

Web標準とオープンソースで良い仕事を提供したい場合は、私に書いてください。

ここにこの投稿にコメントを追加してください。

デニス・プシュカレフ、14年2023月<>日