core-js - core-jsドキュメントを探している場合は、一時的にここに移動されています。

(Standard Library)

Created at: 2013-07-18 00:32:27
Language: JavaScript
License: MIT

ロゴ

募金 PR歓迎 バージョン コアJSのダウンロード コアJSピュアダウンロード jsDelivr

ドキュメントを探している場合は、一時的にここに移動されています。

core-js

後で、この投稿はこのリンクから利用できるようになります。

それで、次は何ですか?

こんにちは。私は(@zloirock)フルタイムのオープンソース開発者です。私は長い投稿を書くのは好きではありませんが、今がそれをする時が来たようです。当初、この投稿は、の新しいメジャーバージョンとロードマップ(後半に移動)の積極的な開発の開始に関する投稿であるはずでしたが、最近の出来事により、さまざまなことについての非常に長い投稿になりました...私はクソ疲れています。無料のオープンソースソフトウェアは根本的に壊れています。私はこれに取り組むのを黙ってやめることができますが、私はオープンソースに最後のチャンスを与えたいと思います。

core-js

🔻クリックして支援方法🔻をご覧ください

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

core-js

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

コアJSとは何ですか?

  • これは、JavaScript標準ライブラリの中で最も人気があり、最も普遍的なポリフィルであり、古代のES5機能からイテレータヘルパーなどの最先端の機能、およびECMAScriptに密接に関連するWebプラットフォーム機能まで、最新のECMAScript標準と提案のサポートを提供します。
    structuredClone
  • これは、最も複雑で包括的なポリフィルプロジェクトです。この投稿を公開した時点では、 から 、 へ 、または まで、または のさまざまなレベルの複雑さを持つ約 5 万のポリフィル モジュールが含まれており、連携して動作するように設計されています。別のアーキテクチャでは、それぞれが別々のパッケージになる可能性がありますが、それほど便利ではありません。
    core-js
    Object.hasOwn
    Array.prototype.at
    URL
    Promise
    Symbol
  • 最大限にモジュール化されており、使用する機能のみをロードするように簡単に(または自動的に)選択できます。グローバル名前空間を汚染することなく使用できます(このようなユースケースを「ポニーフィル」と呼ぶ人もいます)。
  • これはツールとの統合用に設計されており、これに必要なすべてのものを提供します。たとえば、、、および同様のSWC機能はに基づいています。
    @babel/preset-env
    @babel/transform-runtime
    core-js
  • これは、開発者が長年にわたって毎日の開発プロセスで最新のECMAScript機能を使用できる主な理由の1つですが、ほとんどの開発者は、トランスパイラー/フレームワーク/中間パッケージによって提供される間接的に使用するため、この可能性があることを知りません/など。
    core-js
    core-js
    babel-polyfill
  • これはフレームワークやライブラリではなく、開発者はAPIを知っているか、定期的にドキュメントを見るか、少なくともそれを使用していることを覚えておく必要があります。開発者が直接使用したとしても - それはインポートのいくつかの行または構成のいくつかの行です(ほとんどの場合 - ほとんど誰もドキュメントを読んでいないので間違いがあります)、その後、彼らは忘れて、Web標準の機能によって提供されるものを使用します - しかし時々これは彼らが使用するJS標準ライブラリのほとんどです。
    core-js
    core-js
    core-js

約9億NPMダウンロード/ 250億19万NPMダウンロード(月間)、<>万の依存GitHubリポジトリ(グローバル純粋)-大きな数字ですが、実際の広がりを示していません。確認してみましょう。

core-js

私は、Alexaのトップウェブサイトリストで野生の使用状況をチェックする簡単なスクリプトを書きました。明らかな使用状況と使用済みバージョンを検出できます(最新のみ)。

core-js
core-js

使い

現時点では、上位1000のWebサイトで実行されているこのスクリプトは、テストされたWebサイトの52%core-jsの使用状況を検出します。月の満ち欠け(リスト、ウェブサイトなどは一定ではありません)に応じて、結果は数パーセント異なる場合があります。ただし、これは最新のブラウザを使用した最初のページでの単純な検出であり、多くの場合、手動チェックではさらに数十パーセントであることがわかります。たとえば、上のスクリーンショットから、このスクリプトで見つからなかったいくつかのWebサイトの最初のページを、各企業(最初はすでにスクリーンショットにあるMS)Webサイトを繰り返さずに残しましょう(一連のスクリーンショットの後、写真の数は減少します):

core-js

ワッツアップ


リンクトイン


ネットフリックス


QQ


イーベイ


林檎


ファンダム


ポルノハブ


PayPal


バイナンス


スポティファイ

このような手動チェックでは、上位75のWebサイトのうち約80〜100でcore-jsを見つけることができますが、スクリプトは約55〜60で検出されました。もちろん、サンプルが大きいほど割合は減少します。

Wappalyzerは、ブラウザプラグインを使用して、使用済みテクノロジーの検出を可能にし、以前は興味深い結果を示していましたが、現在、Webサイトでは、最も人気のあるテクノロジーの公開結果はすべて約5万件の陽性に制限されています。Wappalyzerの結果に基づく統計はこちらから入手でき、41万のモバイルテストページと44万デスクトップテストページの8%と5%で示されています。現時点でBuilt Withは、トップ54サイトの10000%でcore-jsを示しています(ただし、検出の完全性については確信が持てず、別の現実のグラフを参照してください)。

core-js
core-js

とにかく、core-jsは人気のあるWebサイトのほとんどで使用されていると自信を持って言えます。大企業のメインサイトで使用されていなくても、一部のプロジェクトでは間違いなく使用されています。

core-js

どのJSライブラリがWebサイトでより広く普及していますか?React、Lodash、またはその他の最も話題になっているライブラリやフレームワークではなく、「古き良き」jQueryについてのみ確信しています。

そして、ウェブサイトのフロントエンドだけでなく、JavaScriptが使用されているほとんどすべての場所で使用されていますが、それは十分な統計だと思います。

core-js

ギットハブ

しかし、上記の理由から、core-jsを使用していることを覚えている人はほとんどいません

なぜ私はこれを投稿しているのですか?いいえ、私がどれほどクールであるかを示すためではなく、すべてがどれほど悪いかを示すためです。読む。


1つの人気のある写真から次の部分を始めましょう
xkcd

ティッカー

開始

私は2012年に開発スタックをフルスタックJavaScriptに切り替えました。それはJavaScriptがまだあまりにも生々しかった時代でした - IEはまだ他の何よりも人気がありました、ES3時代のブラウザはまだウェブのかなりの部分を占めていました、最新のNodeJSバージョンは0.7でした - それはちょうどその道を始めたばかりでした。JavaScriptはまだ本格的なアプリケーションを書くのには適しておらず、開発者はCoffeeScriptのような言語のコンパイラで必要な言語構文の砂糖の欠如とUnderscoreのようなライブラリを持つ適切な標準ライブラリの欠如の問題を解決しました。しかし、それは標準ではありませんでした - 時間が経つにつれて、これらの言語とライブラリはそれらを使用するプロジェクトと一緒に時代遅れになります。だから、私は今後のECMAScriptハーモニー6標準のすべてのニュースを大きな希望を持って受け止めました。

古いJavaScriptエンジンの普及と、ユーザーが急いでおらず、それらを放棄する機会がなかったという事実を考えると、新しいECMAScript標準が迅速かつ問題なく採用された場合でも、JavaScriptエンジンを介してのみ使用する機能は何年も延期されました。しかし、いくつかのツールを使用して、この標準からサポート機能を取得しようとすることは可能でした。トランスパイラー(この単語は現在ほど人気がありませんでした)は、構文とポリフィルの問題を解決する必要があります-標準ライブラリを使用します。しかし、当時、必要なツールキットは登場し始めたばかりでした。

ECMAScriptトランスパイラーが普及し、活発に発展し始めた時期でした。ただし、同時に、ポリフィルはユーザーや実際のプロジェクトのニーズに応じてほとんど進化していません。それらはモジュール式ではありませんでした。それらはグローバルな名前空間の汚染なしには使用できなかったので、ライブラリには適していませんでした。それらは1つの複合体ではありませんでした-異なる著者からのいくつかの異なるポリフィルライブラリを使用し、どういうわけかそれらを一緒に動作させる必要がありました-しかし、場合によっては、それはほとんど不可能でした。あまりにも多くの必要な基本的な言語機能が見落とされました。

これらの問題を解決するために、2012年の終わりに、最初は自分のプロジェクトのために、私は後に呼ばれたプロジェクトに取り組み始めました。私はすべてのJS開発者の生活を楽にしたかったので、2014年<>月にオープンソースプロジェクトとして公開しました。多分それは私の人生で最大の過ちでした。

core-js
core-js

これらの問題に直面したのは私だけではなかったので、数ヶ月後、すでにJavaScript標準ライブラリ機能の事実上の標準になっています。 公開の数ヶ月前に登場したBabel(その瞬間)に統合されていました-上記の問題のいくつかは、このプロジェクトにとっても重要でした。 ブランド変更後、として配布され始めました-。数ヶ月のコラボレーションの後、ブランド変更と進化の後になったツールが登場しました。数ヶ月後、主要なフレームワークに統合されました。

core-js
core-js
6to5
core-js
core-js
6to5/polyfill
babel-polyfill
babel-runtime
core-js

Web 全体の互換性の確保

私は自分自身やプロジェクトを宣伝しませんでした。これは2番目の間違いです。 ウェブサイトやソーシャルメディアアカウントはなく、GitHubのみを持っていました。私はそれについて話すために会議に現れませんでした。私はそれについての投稿をほとんど書きませんでした。私はちょうど現代の開発スタックの本当に便利で欲しかった部分を作っていました、そして私はそれについて幸せでした。私は開発者に、互換性やバグについて考えることなく、必要なすべてのエンジンに実装されるまで何年も待たずに、最も近代的で本当に必要なJavaScript機能を使用する機会を与えました-そして彼らはそれを使い始めました。プロジェクトの広がりは指数関数的に成長しました-すぐにそれはすでに人気のあるウェブサイトの数十パーセントで使用されていました。

core-js

しかし、それは必要な作業の始まりにすぎませんでした。長年の努力が続きました。ほぼ毎日、私は関連するプロジェクト(主にBabelと互換性のあるテーブル)のメンテナンスに数時間を費やしました。

core-js

ギットハブ

core-js
あなたが書いてそれを忘れることができる数行のライブラリではありません。大多数のライブラリとは異なり、Webの状態にバインドされています。JavaScript標準や提案の変更、新しいJSエンジンのリリース、JSエンジンのバグの検出などに対応する必要があります。ECMAScript 6 2015の後、新しい提案、ECMAScriptの新しいバージョン、新しい非ECMAScriptウェブ標準、新しいエンジンとツールなどに従いました。進化、プロジェクトの改善、そしてWebの現在の状態への適応は決して止まらず、この作業のほとんどすべてが平均的なユーザーには見えないままです。

必要な作業の規模は絶えず拡大していました。

私は長い間、他のメンテナまたは少なくとも一定の貢献者をさまざまな方法で見つけようとしましたが、すべての試みは失敗しました。ほとんどすべてのJS開発者は間接的に使用し、たとえば、、、または彼のフレームワークが必要なすべての機能をポリフィルすることを知っていましたが、ほとんど誰も知りませんでした。言及されたポリフィリングに関するいくつかの投稿では、それは「小さな図書館」と呼ばれていました。それは流行で広く議論されたプロジェクトではなかったので、とにかくうまくいくのなら、なぜそれを維持するのを手伝うのですか?時間が経つにつれて希望を失いましたが、コミュニティへの責任を感じ、一人で働き続けることを余儀なくされました。

core-js
core-js
babel-polyfill
babel-runtime
core-js
core-js

フルタイムの仕事とFOSSを組み合わせることは数年後、ほとんど不可能になりました-誰もFOSSに捧げられた労働時間にお金を払いたくありませんでした、非労働時間は十分ではなく、時には数週間完全に没頭する必要がありました。コミュニティには適切なポリフィリングが必要であり、お金は私の優先事項ではないと思いました。

core-js

私は高給の仕事を辞め、それらのポジションではオープンソースに取り組むのに十分な時間を費やす機会がなかったため、いくつかの非常に良いオプションを受け入れませんでした。私はフルタイムでオープンソースに取り組み始めました。誰も私にそれを払ってくれませんでした。遅かれ早かれ、オープンソースとWeb標準に完全に専念できる仕事を見つけることを望んでいました。定期的に、私は短期契約で、FOSSでの生活と仕事に必要なお金を稼ぎました。私はロシアに戻り、そこでは比較的小さなお金でまともな生活水準を得ることができました。もう1つの間違い-以下に示すように、お金は重要です。


2019年3月まで、全体で約<>年半、フルタイムで約半年間、他の仕事に気を取られることなく、現在ほとんどどこでも使用されているツールキット世代の地下室であるポリフィリング関連のBabelツールを根本的に改良したコアjs@<>に取り組みました。

事故

たわごとはリリースの3週間後に起こりました。3月のある夜、午前18時、私は車で家に帰っていました。暗い服を着た7人の致命的な酔っ払った<>歳の女の子は、どういうわけか薄暗い高速道路を横切って這うことに決めました-そのうちの<>人は道路に横になり、もう<>人は座って最初のものを引きずりましたが、道路からではなく-私の車輪の真下。それは目撃者が言ったことです。私はそれらを見る機会がまったくありませんでした。もう一人の目撃者は、事故の前に彼らはただ冗談めかして道路で戦っていたと言いました。珍しいことは何もありません、それはロシアです。そのうちの<>人は死亡し、もう<>人の女の子は病院に行きました。しかし、この場合でも、ロシアの裁定取引慣行によれば、運転手が代理人の息子またはそのような人でない場合、彼はほとんどの場合有罪とされます-彼はすべてを見て予測する必要があり、歩行者は誰にも何も負いません。私は長い間刑務所に入れられる可能性があります、IIRCは後に検察官が<>年を要求しました。

core-js@3

刑務所に入れられない唯一の方法は、「犠牲者」との和解-そのような事故の後の標準的な慣行-と優れた弁護士でした。事故から数週間以内に、私は「犠牲者」の親戚から当時の為替レートで合計約80万ドルの金銭的請求を受けました。弁護士にもかなりの金額が必要でした。

優れたソフトウェアエンジニアにとっては考えられないほどのお金ではないかもしれませんが、少し上で書いたように、私は長い間フルタイムでリリースに取り組んでいました。もちろん、誰も私にこの仕事にお金を払わなかった、そして私はすべての私の財政的準備金を完全に使い果たした、それで、確かに、私はそのようなお金を持っておらず、利用可能な情報源から必要なお金を見つける機会がなかった。私が持っていた時間は尽きていました。

core-js@3

募金

その時までにすでに現在とほぼ同じくらい広く使用されていました。上で書いたように、長い間、私は貢献者を探しましたが、成功しませんでした。ただし、積極的に維持されるべきプロジェクトであり、凍結したままにすることはできません。私の長期投獄は、私だけでなく、それを使用するすべての人にとっても問題を引き起こしたでしょう-ウェブの半分にとって。悪名高いバス要因

core-js
core-js
core-js
core-js

その数ヶ月前に、私は開発を支援するための資金を調達し始めました(主にGitHubとNPMにREADMEが掲載されていました)。結果は... 月額57ドル。ウェブ😂全体の互換性を確保するためのフルタイムの作業に対する公正な支払い

core-js

私は少し実験をすることにしました-ユーザーに助けを求めるために-メンテナンスなしで放置された場合に苦しむ人々。インストール時にメッセージを追加しました:

core-js
core-js
core-js

ポストインストール

寄付に必要なすべてのお金を手に入れることはほとんどないことを理解しましたが、すべてのドルが重要でした。別のパートを獲得するチャンスを得るために、就職活動メッセージを追加しました。NPMインストールログのいくつかの行で支援を求めていますが、必要に応じて非表示にすることができますが、使用するのに許容できる価格です。当初の計画では、この投稿を数週間で削除する予定でしたが、すべてが計画に反していました。私が人々についてどれほど間違っていたか...

core-js

憎む

もちろん、誰かが自分のコンソールで助けの要求を見たくないと思っていましたが、私が受け始めた憎しみの絶え間ない流れは屋根を通り抜けました。それは一日で何百ものメッセージ、投稿、コメントでした。これはすべて、次のようなものに減らすことができます。

ゲットリッド

これは私が見た中で最も面白いものとはほど遠いです-私が望むなら、私はここで集められたスタイルでステートメントの膨大な選択を集めることができました-しかしなぜですか?私はすでに私の人生に十分な否定性を持っています。

開発者は無料のオープンソースソフトウェアを使用するのが大好きです-それは無料でうまく機能し、何千時間もの開発には興味がなく、独自の問題とニーズを持つ実際の人々がその背後にいます。彼らは、これについての言及を彼らの個人的な空間の侵入、あるいは個人的な侮辱としてさえ考えています。彼らにとって、これらはノイズや参加なしに自動的に変化するはずの単なるギアです。

それで、何千人もの開発者が侮辱で私を攻撃し、私には彼らにどんな種類の助けを求める権利もないと主張しました。私の助けの要求は彼らを非常に怒らせたので、彼らはリポジトリとパッケージへの私のアクセスを制限し、左パッドで行われたようにそれらを他の誰かに移動することを要求し始めました。彼らのほとんど誰も、プロジェクトの規模が何であるかを理解していませんでした、そしてもちろん、彼らの誰もそれを維持したいとは思っていませんでした-それは「コミュニティ」、他の誰かをするべきです。このすべての憎しみを見て、憎しみに導かれないようにするために、私は当初、原則から外れて数週間だけ追加する予定だった助けを求めるメッセージを削除しませんでした。

core-js

core-jsが大きなお金を稼ぐのを助け、助けた企業はどうですか?それはほとんどすべて大企業です。この古いツイートを言い換えてみましょう:

会社名: "SQL Server Enterprise を使用したい"

MS:「それは四百万ドル+ $ 20K /月になります」

会社:「わかりました!」

...

会社: 「コアjsを使いたい」

コアJS: "わかりました!npm i core-js"

会社名:「かっこいい」

core-js:「財政的に貢献するのを手伝ってくれませんか?」

会社:「笑いの」

数か月後、ユーザーの苦情にうんざりして、NPMはnpm基金を提示しました-それは問題の解決策ではなく、それらの苦情を取り除くための単なる方法でした。どのくらいの頻度で電話しましたか?あなたが見た人にどのくらいの頻度で寄付をしましたか?最初に誰を見てサポートしましたか、それとも相互に依存する1行ライブラリを12個維持している人ですか?また、NPMは将来のステップ(以下を参照)の完璧な正当化を提供しました。

npm fund
npm fund
core-js

9か月以内に、根本的に依存するプロジェクトの開発者を含む何千人もの開発者が状況を知っていましたが、誰も維持することを申し出ませんでした。何ヶ月も経たないうちに、私はに依存するいくつかの重要なプロジェクトのメンテナと話をしましたが、成功しませんでした-彼らは時間リソースを必要としませんでした。そのため、FOSSコミュニティとは関係のない友人の何人か(最初は@slowcheetah、彼の助けに感謝します)に私をカバーし、少なくとも私が自由になるまで重大な問題を修正しようとするように頼むことを余儀なくされました。

core-js
core-js
core-js


サポートしているユーザーや中小企業はほとんどいませんでしたが、私は彼らにとても感謝しています。しかし、9か月以内に、何かを変えるために数週間以内に集められるべきだったお金の約1/4しか集められませんでした。

core-js

同時に、すべてにもかかわらず、一日のダウンロード数はほぼ倍増しました。

core-js

2020年<>月、私は刑務所に入れられました。

解放

私は刑務所について多くの言葉を言いたくありませんし、これを覚えておくことはそれほど望んでいません。それは私の健康が著しく台無しにされた化学工場での奴隷労働であり、私は24時間年中無休で麻薬の売人、泥棒、殺人者(他の政権から)の会社で素晴らしい時間を過ごしました。

約10か月後、私は早期に解放されました。


私は数十の記事、数百の投稿、そして何千ものコメントを見ましたが、その本質の多くはこれで表現できます。

レディット

私が何をしたと思いますか?もちろん、私も同じ間違いを犯しました。私は、多くの問題、質問、メッセージの開発を支持した何人かの人々を見ました-確かに、怒りのコメントほどではありません。 さらに人気が高まり、現在とほぼ同じ割合のWebサイトですでに使用されていました。

core-js
core-js

Web全体の互換性を再び確保する

以前のようにメンテナンスに戻りました。さらに、私は契約やその他の作業に気を取られることを完全にやめました。 資金調達プラットフォームにいくらかのお金がありました-フルタイムで仕事を始める前に受け取ったよりもそれほど多くはなく、何倍も少なかった-しかし私だけにとってそれは人生のために十分でした。世界をより良くするための一種のダウンシフト、フルタイムのオープンソース...事故で残った数万ドルの訴訟については考えていませんでした。私は自分の将来について考えていませんでした。私はウェブのより良い未来について考えました。そしてもちろん、私はどこかの会社が私にウェブ標準に取り組む機会のあるポジションを提供し、ポリフィルとFOSSに関する私の仕事を後援してくれることを望んでいました。

core-js
core-js
core-js
core-js

今後8年間で多くのことが達成されました-仕事の面では、過去<>年間とほぼ同じです。これはまだですが、はるかに優れています。ただし、変更ログと以前の差分でさえ、行われた作業の数パーセントしか反映していません。この作業のほとんどすべてが影に残り、平均的なユーザーには見えません。

core-js@3

これは標準と提案を伴う基本的な作業です。この作業の副作用として、行われたハードワークとフィードバックと提案の後の変更を考慮して、言語の一部となったECMAScript提案の多くは、チャンピオンの成果であると同時に私の成果であると考えています。これは、バグを検索する際のエンジンとそのバグトラッカーの操作です。これは、どこでも標準ライブラリの適切な動作を保証し、互換性のあるデータを収集するための、何百もの環境、何千もの環境/ビルド/テストスイートの組み合わせでの絶え間ない自動および(あまりにも頻繁な)手動テストです。数日で作成された生のプロトタイプから、互換性のあるデータは、適切な外部および内部ツールを備えた網羅的なデータセットになりました。これは、プロジェクトにまだ登場していない多くの機能の設計とプロトタイピングです。そしてまた、はるかに。

core-js


上記のように、人気のあるWebサイトのほとんどに存在し、ほぼ完全なJavaScript標準ライブラリを提供し、適切な実装ではない問題を修正します。ウェブページの開封数が、Safari および Firefox のウェブページの開封数よりも多い。したがって、ある観点からは、最も人気のあるJavaScriptランタイムの1つと呼ぶことができます。

core-js
core-js
core-js

作業中、私はほとんどすべての現代および将来のJavaScript標準ライブラリ機能の最初の実装者であり、それらのほとんどすべてに私のフィードバックがあり、それに従って修正されています。 は、ECMAScriptの提案を試すのに最適な遊び場です。多くの場合、提案は、提案の実験的な実装で遊んだ後、他のユーザーからのフィードバックを受け取ります。

core-js
core-js
core-js

JavaScriptの最善の方法は、TC39とJavaScriptの将来に向けて協力することです。たとえば、TC39は、Babelなどのプロジェクトのメンバーを専門家として招待します。しかし、そうではないようです。これの代わりに、あまりにも頻繁に、私は自分の問題を無視したり、TC39メンバーによって障害物を作ったりしますが、彼らはそれを隠していません。

core-js
core-js
core-js

集


ティッカー


しばらくして、NPMから「サポート」が来ました。これは、インストール後のスクリプトでコンソール出力が無効になった論理的な継続として2020年末にリリースされました。結果は予想されていました-人々は資金調達要求を見るのをやめ、ほとんど誰も使用しなかったため、支援者の数は減少し始めました。私の作品を配布することで稼ぐだけでなく、自分でそれを使用する人々からのプロジェクトへの優れたサポート-)

npm@7
npm fund
npm fund
core-js

ティッカー

さらに、別の要因が再び作用しました。より高い品質 - より少ないサポート。図書館は手入れが行き届いていますか?未解決のバグレポートはほとんどなく、発生した場合、ほぼ瞬時に修正されますか?図書館はすでに私たちが望むほとんどすべてを与えてくれますか?はい。では、なぜ図書館のメンテナンスをサポートする必要があるのでしょうか。これがメンテナのために行われる価格は表面的ではありません - ほとんどの場合、それはまだ単なる「小さなライブラリ」です。以前に支援した人の多くはそれをやめました。

core-js

core-js
コードには私の著作権が含まれています。この投稿の上部にあるように、すべてのWebサイトの約半分に存在します。定期的に誰かが有害なサイト/アプリケーションのソースコードでそれを見つけます-しかし、彼らは何であるかを知らず、彼らの技術レベルはそれを見つけるのに十分ではありません。その後、警察は私を呼んで脅迫し、誰かが私を脅迫しようとさえします。時にはそれは面白くないことさえあります。
core-js

私は、アメリカのニュースや政府のウェブサイトで発見したアメリカ人とカナダのジャーナリストから何度か連絡を受けました。彼らは、私がアメリカの選挙に干渉する邪悪なロシアのハッカーではなかったことに非常に失望しました。

core-js

果てしない憎しみの流れは時間とともにわずかに減少しましたが、続きました。しかし、そのほとんどはGitHubの問題やTwitterのスレッドのようなものから私のメールやIMに移行しました。今日、ある開発者が私にメッセージを書いた。彼は私を開発者コミュニティの体の寄生虫と呼び、スパムや何も役に立たないことで大金を稼いでいます。彼は私をハンス・ライザーと同じ殺人者と呼んだが、裁判官を買って罰せられなかった。彼は私と私のすべての親戚の死を望みました。そして、ここで珍しいことは何もありません、私は月にいくつかのそのようなメッセージを受け取ります。昨年、これは私が「ロシアのファシスト」であると付け加えられました。

戦争について一言

オープンソースは政治から外れるべきです。

私は2種類の悪のどちらかを選びたくありません。国境の両側に私の近くにこのために苦しむかもしれない人々がいるので、これについてはこれ以上詳しくコメントしません。

私が上で書いたことを思い出させてください-ロシアに戻ったのは、比較的小さなお金でまともな生活水準を持ち、お金を稼ぐ代わりにFOSSに集中できる場所だったからです。事故の後、私は数万ドルの未解決の訴訟を起こし、それらが完済されるまで国を離れることを禁じられているので、今私はロシアを離れることができません。

あなたはどう思いますか、月にいくらのお金を稼ぎますか?
core-js

契約やその他の仕事に気を取られることなくフルタイムを維持し始めたとき、それは月に約2500ドルでした-それは私が通常フルタイムの契約で持っていたよりも約4〜5倍少なかったです。Webをより良くするための一種のダウンシフトであることを忘れないでください。仮に。問題やバグをゼロに減らし、ほとんどすべての人が使用する最高品質の製品を作りましょう-そしてプロジェクトは十分にサポートされますよね?右。

core-js

数ヶ月後、毎月のリピートは約1700ドルに減少しました(少なくともそれは私が思ったことです)-Tidelift経由で1000ドル、Open Collective経由で600ドル、Patreon経由で100ドル。毎月の繰り返しに加えて、100回限りの寄付が定期的に行われます-平均して、おそらく<>か月で<>ドルでした。

隠れ。寄付用の暗号ウォレットを追加することは非常に人気のある要求でした。ただし、常に、暗号ウォレットで受信されたのは合計約$2の200回の転送のみであり、以前の転送は60年以上前のものです。GitHub のスポンサーですか?それはロシアでは利用できず、決してありませんでした。PayPal。ロシア人には禁止されています。それが利用可能になったとき、すべての時間のために約<>ドルを受け取りました。補助 金。私はたくさんの助成金を申請しました-すべて無視されました。

core-js

主な部分、月額400ドル、それらの寄付から、core-jsは...バウアー、別のFOSSコミュニティ。私は他のすべてのスポンサーにも非常に感謝しています-あなたの寄付のおかげで、私はまだこのプロジェクトに取り組んでいます。

ただし、このリストには、大企業や少なくともトップ1000のWebサイトリストの会社はありません。正直に言うと、主に個人がいて、現在の支援者のリストには少数の中小企業しかなく、月に数ドルを支払います。

誰かがそれが資金を必要とすることを知らないと言うなら...さあ、私は定期的にこのようなミームを見ます:

core-js

サンダース


一年前、タイドリフトは私にお金を送るのをやめました。彼らは、政治情勢のために、彼らが使用したHyperwalletはもはやロシア人には利用できず(しかし、私がいくつかの個人データを更新しようとした前月まで私に利用可能でした)、安全のために、彼らは私のお金を彼らの側に保管します。過去数か月以内に、私はこのお金を銀行またはHyperwalletアカウントに取り込もうとしましたが、彼らが何かをしようとするという返事しか受け取りませんでした(素晴らしいですね)。前年末から、彼らは電子メールへの応答を停止しました。そして今、私はこれを持っています:

潮汐リフト

とても面白い方法で、私は前年のお金を受け取らないことを知り、今年は1800ドルではなく、月に800ドルで働きました。もちろん、その後のメールへの返信はありませんでした。しかし、彼らのサイトは、私が彼らを通してお金を受け取り、まだ受け取っていることを示しました。

潮汐リフト

依存関係をサポートする企業は、そのような詐欺にどのように反応するのだろうか。


同じ日に、OpenCollectiveで、毎月のリピートが約600ドルから約300ドルに減ったのを見ました。どうやら、の財政準備金は終わりました。つまり、今月は約400ドルになります

Bower

前の月に、私は作業にかかる時間を測定しました。それは判明しました...月に250時間-休日のない丸一日よりもはるかに多いため、「実際の」(多くの人が言うように)フルタイムの仕事をしたり、重要な契約を結んだりすることは不可能です。400時間で250ドル...2時間あたり4ドル未満になりますが、前年はもう少し多くなります-<>時間あたり<>ドルです。はい、数か月で、私はプロジェクトに取り組む時間を減らします-しかし、それはあまり変わりません。

core-js

Web全体の互換性を確保するために喜んでお金を払う。そして、保険や社会保障はありません。

素晴らしい収益の成長とキャリアですよね?

主要なIT企業のシニアソフトウェアエンジニアがどれだけの報酬を得ているかをよく理解していると思います。私は多くの同等のオファーを受け取りましたが、それらは適切な作業と互換性がありません。

core-js


定期的な脅迫、告発、要求、侮辱の中で、私はしばしば「物乞いをやめて仕事に行きなさい、アイドラー。物乞いのメッセージをすぐに削除してください-私はそれらを見たくないのです。」面白いことに、これらの人々の少なくとも何人かは年間300,000万ドル以上を稼ぎ(私は彼らの同僚と話しているので確かに知っています)、そして(彼らの仕事の性質のために)彼らに毎月何時間もの仕事を節約します。

core-js

すべてが変わる

私が働き始めたとき、私は一人でした。今、私には家族がいます。数年前、私は息子の父親になりました。今、私は彼にまともな生活水準を提供しなければなりません。

core-js

息子

私には妻がいて、時々彼女は新しい靴やバッグ、新しいiPhoneやApple Watchを欲しがっています。私の両親はすでに私が彼らを大幅にサポートする必要がある年齢になっています。

私が持っている、または維持から持っていたお金で家族を適切にサポートすることは不可能であることは明らかだと思います。私が使った準備金は、ついに終わりました。

core-js

ますます頻繁に私は次のような非難を聞きます:「あなたのオープンソースをあきらめなさい、これは甘やかされています。通常のジョブに戻ります。 プログラマーとして1年間だけ働いています。彼はそれについてほとんど何も理解しておらず、一日に数時間働き、すでにあなたの何倍も稼いでいます。」

%USERNAME%

これ以上はない

私はいまいましい疲れています。私はオープンソースに取り組むのが大好きです。しかし、私は誰のために、または何のためにこれをしているのですか?上記を要約しましょう。

core-js

  • 私は互換性の問題がないことを確認し、2014年からほとんどのWebにWebプラットフォームの最先端の機能を提供し、今では食べ物でも十分ではないお金のためにほとんどすべての時間に取り組んでいます。
  • 感謝の代わりに、私が見るのは、私が人生を単純化する開発者からの大きな憎しみだけです。
  • 使用量を節約して数百万ドルを稼ぐ企業は、資金調達要求を無視するだけです。
    core-js
    core-js
  • 危機的な状況でも、助けを求めると、助けの代わりに、彼らのほとんどは無視するか憎むことを好みました。
  • JavaScriptのより良い未来のために標準やブラウザの開発者と協力する代わりに、私は彼らが作る障害と闘うことを余儀なくされています。

私は嫌いな人を気にしません。そうでなければ、私はずっと前にオープンソースを離れるでしょう。

私は標準開発者との通常の相互作用の欠如を容認することができます。まず第一に、それはユーザーにとって、そしてWebが壊れるとき、標準開発者自身にとって将来の問題です。

しかし、お金は重要です。私は私と私の家族の幸福を犠牲にして企業を後援するのに十分でした。私は私の家族のために、私の息子のために明るい未来を確保することができるはずです。

作業には、ほぼすべての時間がかかり、丸一日以上かかります。この仕事は人気のあるウェブサイトのほとんどで適切な仕事を保証し、この仕事は適切に支払われるべきです。私は無料または時給2ドルで働き続けるつもりはありません。私は少なくとも時給80ドルでプロジェクトに取り組み続けるつもりです。これは、たとえば、チームメンバーが<>時間エスリントしているお金です。そして、オープンソースでの作業でそれが必要な場合は、訴訟を完済してロシアを離れる準備ができていますが、安くはありません。

core-js


定期的に私はこのようなコメントを見ます:

コアJSアプローチ

わかりました、あなたがそれを望むなら-そのようなアプローチを使いましょう。


フィードバックに応じて、すぐに次のいずれかの方法に従います。
core-js

  • 適切な財政的裏付け

    少なくともこの投稿を読んだ後、企業、中小企業、および開発者が最終的に開発スタックの持続可能性について考え、開発を適切に支援することを願っています。この場合、適切に維持され、新しいレベルの機能の追加に集中できるようになります。

    core-js
    core-js

    必要な仕事の規模は屋根を通り抜けます、私の一人はもはや十分ではありません-私はもっと肉体的に働くことができません。たとえば、テストカバレッジやドキュメントの改善など、一部の作業は十分に単純で時間がかかりますが、ボランティアがやりたい種類の作業ではありません-既存の機能のテストカバレッジを改善するPRを覚えていません。したがって、有料ベースで少なくとも1人または2人の開発者(少なくとも学生、より良い-より高いレベル)を引き付けることは理にかなっています。

    追加のメンテナの関与やその他の費用を考慮すると、現時点では30か月で約<>万ドルで十分だと思います。より多くのお金-より良い製品とより速い開発。数倍少ない-フルタイムだけで作業を再開することは理にかなっています-確かに、チームの場合ほど生産的ではありません。

    core-js

  • オープンソースやWeb標準に取り組むことができる会社に雇われるかもしれません

    そして、それは私に仕事の継続に必要なリソースを与えるでしょう。

  • core-jsは、ユーザーからの適切なサポートがない場合、商用プロジェクトになります

    現在のパッケージの周りに商用インフラストラクチャを作成するのは問題なので、おそらく新しいメジャーリリースでライセンスが変更されるでしょう。無料版は大幅に制限されます。すべての追加機能は有料です。 適切に進化し続け、このプロジェクトの範囲内で、Web互換性を確保するための多くの新しいツールが作成されます。確かに、それはの広がりを大幅に減らし、多くの開発者に問題を引き起こしますが、一部の有料顧客でさえ十分であり、私の家族は請求書を支払うためのお金を持っています。

    core-js
    core-js
    core-js
    core-js

  • それが必要ではないことがわかった場合に備えて、ゆっくりとした死

    core-js

    私は商業プロジェクトのための多くのアイデアを持っています、私はたくさんの良い仕事の申し出を持っています - これはすべて時間がかかります、そしてそれは今メンテナンスに行きます。それは私がすぐに維持するために完全に停止するという意味ではありません-私はただ比例配分された寄付を維持します。それらが現在のレベルにある場合、それは今の数百時間ではなく、月に数時間のメンテナンスになります。プロジェクトは成長を停止します-おそらくマイナーなバグが修正され、互換性データが更新されます-今回はそれ以上の時間ではありません。しばらくすると、役に立たなくなり、死んでしまいます。

    core-js
    core-js
    core-js

現代のデジタルインフラストラクチャの重要な要素の1つであるため、最初の結果をまだ期待していますが、現在と過去を見ると、精神的に他のオプションの準備をしています。

core-js

私は定期的に目にするいくつかの怒りのコメントに事前に答えます、そしてそれは間違いなくこの投稿の後になるでしょう:

  • 「問題ありません。core-js依存関係を固定するだけです。」

    ほとんどのプロジェクトとは異なり、JavaScriptの最先端にいることができるので、最先端にいる必要があります - 最新のJavaScript機能を使用して、エンジンの互換性やバグについて考えないでください。ただし、図書館には将来のための十分な安全マージンがあります。たぶん一年かカップルの間、あなたは深刻な問題を抱えることはないでしょう。その後、それらは表示されます-ポリフィルは廃止されますが、それでもバンドルに存在し、役に立たないバラストになります。言語の新機能を使用できなくなり、JSエンジンの新しいバグに直面します。

    core-js
    core-js

  • 「それはオープンソースです、私たちはそれをフォークします、ファックオフ。」

    私はそのようなコメントを定期的に見ます、誰かがフォークで私を怖がらせようとさえします。誰かがcore-jsをフォークして適切に保守するなら、私は幸せだと何度も言いました-メンテナンスなしでフォークするだけでは意味がありません。今では、何か重要なものに追加しようとしたり、少なくとも定期的に貢献したりしようとする人さえ見当たりません。互換性データを更新するために、新しいJavaScriptエンジンのリリースごとに反応し、各エンジンからの新しい(どれほど重大であっても)バグを修正するか、少なくとも考慮に入れ、可能な各新しいJavaScript機能を確認して実装し、最大限に適切に実行し、各最新またはレガシーエンジンの各バージョンの詳細をテストして考慮する必要があります-それは大変な作業です-準備ができていて、必要な知識と時間がありますかそのためには。たとえば、私が刑務所にいたとき、バベルは彼らがそうではないと言いました:

    core-js

    バベル

  • コアjsは必要ありません。多くの代替プロジェクトが利用可能です。」

    誰もあなたを抱きしめていません。しかし、それらの選択肢は実生活のどこにありますか?確かに、JavaScript標準ライブラリの唯一のポリフィルではありません。しかし、他のすべてのプロジェクトは、よりも数十人気がなく、不合理ではありません-それらはすべて機能のほんの一部しか提供せず、適切で複雑ではなく、使用できるケースの数が大幅に制限されており、そのような簡単な方法でプロジェクトに適切に統合できず、他の重大な問題があります。適切な代替案が存在する場合、私はずっと前に作業をやめます。

    core-js
    core-js
    core-js
    core-js

  • 「IEのサポートをやめることができるので、ポリフィルはもう必要ありません。」

    私が少し上に書いたように、誰もあなたを抱きしめていません。場合によっては、ポリフィルは実際には必要ではなく、回避できますが、それはすべてのケースのほんの一部であり、IE時代とほぼ同じです。もちろん、IEのサポートが必要ない場合、ポリフィルはIE6にES8サポートを追加する場合ほど可能性を広げません。しかし、最新のエンジンでさえ、最新のJavaScript機能を実装していません。最新のエンジンにもバグが含まれています。あなたとあなたのチームは、サポートするすべてのエンジンのすべての制限を完全に理解しており、それらを回避できると確信していますか?私でさえ時々いくつかの瞬間を忘れるかもしれません。

  • 「あなたはろくでなしです、私たちはあなたをFOSSコミュニティから追放します。」

    はいそうです。私は、実際の生活で最新のJavaScript機能を使用する機会を与え、長年にわたってエンジン間の互換性の問題を解決し、他の誰よりもこれを犠牲にしてきたような嫌いな人です。私は息子に十分な栄養を与えたいだけで、家族に請求書を支払うお金があり、何も必要としないような嫌いな人です。上記のいくつかのオプションは、商用ソフトウェアを支持してFOSSを離れることを前提としています。


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

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.

conversion

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
, Babel and a look into the future post, but that were just raw ideas. Now it's in the stage of experimentation or even implementation.

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
was released about 4 years ago - it's too much. It's not a big problem for me to add some breaking changes (rather ensuring backward compatibility is often a challenge) and to mark a new version as a major release - it's a big problem for users.

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
polyfill was relatively recently added. During work on it, taking into account the dependencies, 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. In the case of polyfills, 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 what I spend on ECMAScript polyfills. So adding the maximum possible web standards support to will be started only in case I have such resources.
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
release, after that we got the current state of statically analysis-based tools for polyfills injecting.
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
and
runtime
are the only enough good and well-known ways to optimize usage of with statical analysis. It happened historically because I helped Babel with polyfills. It does not mean that it's the only or the best place where it could be done.
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
optimization, but it's still not perfect). However, why do we talk about the transpilers layer? The bundlers layer and tools like or
esbuild
(that also contains an integrated transpiler) are more interesting for the optimization of polyfills. Rome in development for several years and still is not ready, but its conception looks very promising.
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
usage statistics above. In many cases, you could see the duplication of - and it's only on the first loaded page of the application. Sometimes it's even like what we see on the Bloomberg website:
core-js

bloomberg

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
(I hope that the Bloomberg team will fix it ASAP, so the result could be outdated).

bundlescanner

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

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
project from Financial Times is based on this conception and it's a great service. The main problem with this project - it's a great service that uses bad polyfills. This project polyfill only a little part of ECMAScript features that provides, the main part of polyfills are third-party and are not designed to work together, too many don’t properly follow specs, too raw or just dangerous for usage (for example,
WeakMap
looks like a step-by-step implementation of the spec text
, but the absence of some non-spec magic cause memory leaking and linear access time that makes it harmful, more other - instead of patching, fixing and reusage of native implementation in engines like IE11 where it's available, but does not accept an iterable argument,
WeakMap
will be completely replaced
). Some good developers try to fix this from time to time, but polyfills themselves are given unforgivably little time, so it's still too far from something that could be recommended for usage.
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

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


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

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