皆さんこんにちは！私は js-framework-benchmark リポジトリの速度の問題を解決するのに 2 年半を費(fèi)やしましたが、最近気づいた非常に興味深い観察があるため、後悔はしていません。

基本的に、すべてのフレームワークとライブラリの開発者は、Web 開発の初期段階で速度の問題に直面しました。これが最も重要なことです。ユーザーが UI 上でデータの変更を早く確認(rèn)できるほど、費(fèi)やす時(shí)間が短縮されるからです。サイトの動(dòng)作が 10% 速くなったら、何十億もの人々の命が何年も救われることを想像してみてください。

何かをしなければならなかったので、おそらく他の理由で、最新のフレームワークとライブラリのベンチマークを備えた多くのリポジトリが作成されました。そのようなリポジトリの 1 つは js-framework-benchmark です。これには、UI を作成するためのほとんどすべての一般的なフレームワークとライブラリが含まれています。

主なタスクは、データに応じたテーブルを描畫することです。これは単純なタスクのように思えますが、実際には、非常に示唆に富むものです。アプリケーションは何にでも似ているが、コンポーネント、DOM 內(nèi)のそれらのシーケンスはブラウザーと連動(dòng)し、その他 - 通常のサイトの動(dòng)作を模倣します。なぜなら、表の行やページのヘッダーはすべて一般的なものであり、一般的なものの 1 つのコンポーネントにすぎないからです。

アプリケーションはコードと時(shí)間を依存関係として正常に動(dòng)作しているため (表示や色は考慮していません。ネットワーク上では 0 と 1 であると言えるため、そのような依存関係は 2 つだけです)、少なくとも 1 つのコンポーネント、少なくとも 100 萬の異なって絡(luò)み合ったコンポーネント - すべてが 1 つのエンジン上にあるため、特別な意味はありません。したがって、ここでは単純さが明瞭であるため、さらに適しています。

ということで、課題はあるのですが、それを何らかの方法で解決する必要があります。プログラミングは、1 つの數(shù)學(xué)的問題を 100 萬通りの異なる方法で解決できるので良いものですが、肝心なことは、基本的な理想的なアルゴリズムは誰にとっても同じであるということです。これは定理であり、何をどのように実裝するかは好みと利便性の問題です。

インターフェイスを見てみましょう。どのようなものですか:

テストアプリ:

結(jié)果の一部:
https://krausest.github.io/js-framework-benchmark/2024/table_chrome_130.0.6723.58.html

狀態(tài)が変化したときに発生する可能性のあるさまざまなキーアクションの結(jié)果が表に示されています。作業(yè)の速度を測(cè)定し、どのコードがより速く動(dòng)作し、どのコードがより遅く動(dòng)作するかを比較できます。これは、すべてのフレームワークとライブラリに平等な競(jìng)爭(zhēng)の場(chǎng)を生み出すため、非常に便利です。しかし、速度だけが問題であればいいのですが、構(gòu)造そのものの基準(zhǔn)も定められており、それが正しくなければなりません。コンポーネントのアプローチ、主要な実裝、狀態(tài)、その他の用語がすべてこれに含まれます。そのような標(biāo)準(zhǔn)がなければ、これは単に実用的なトピックではありません。

つまり、標(biāo)準(zhǔn)はフレームワークやライブラリの作成者によって長(zhǎng)い間設(shè)定されてきました。それを行う人にとっては明白であり、理解できるものです。問題は、UI が迅速にレンダリングされるように、これらすべてを何らかの方法で高速作業(yè)に適応させる必要があるということです。

そこで、「大規(guī)模な」フレームワークやライブラリとそれほど大きくないフレームワークやライブラリの作成者全員、そして自分の手を試してみたいと考えている愛好家だけを集めるという素晴らしいアイデアです。スポーツと同じように、私たちにはコミュニティがあり、問題に対するさまざまな解決策が公開される「リーダー」の委員會(huì)があるため、これはすべて重要です。これは単なる數(shù)學(xué)であるため、プログラミングの観點(diǎn)からはあまり良い比較ではありませんが、このアイデア自體は興味深いものです。なぜなら、このアイデアは人々に美しく素早く実行するように促し、そして最も重要なことに、それは正しいからです。

そうですね、このようなコミュニティは近年、現(xiàn)在および將來のすべてのクリエイターが現(xiàn)在使用できる多くのクールなソリューションを生み出してきました?；镜膜圣ⅴ毳触辚亥啶悉工扦擞浭訾丹欷皮い毪郡?、車輪を再発明する必要はありません。この理解により、多くの年月を節(jié)約できます。

多くの開発者がすでに理想的なコードを?qū)g裝する例を書いています。これに基づいてコードを作成するのは非常に簡(jiǎn)単です。したがって、最も良いことは、このようなことは以前には起こらず、特にこのリポジトリのおかげで起こったことです。誰が何と言おうとカッコいいです

コンポーネントごとに理想的なアルゴリズムを検討する場(chǎng)合、主要な実裝のアルゴリズム (最長(zhǎng)増加サブシーケンスまたはその別のバリエーションを使用)、テンプレートの複製、直接の反応性 (textContent、addEventListener、classList.add)、または現(xiàn)在は役に立たない VDOM を使用していますが、テンプレートに関しては必要ですが、狀態(tài)の操作やコンポーネント間のインポートについては、最後の 2 つは議論の余地があります。しかし、これが基礎(chǔ)であり、ここで他に何も発明することはできません。

ベンチマーク リポジトリにコードがたくさんあるため、この記事にはコード自體は含まれません。

とにかく、今日ではデータを表示するための理想的なコードがすでに存在しており、車輪を再発明することなく、それを考慮に入れてそれに基づいて何か新しいことを行うだけの価値があることを、人々がすぐに理解してくれることを願(yuàn)っています。今日の多くのライブラリとフレームワークは、はるかに高速かつ効率的に動(dòng)作できますが、従來のコードではこれができないだけです。作業(yè)量が膨大になる可能性があり、すべてをやり直さなくても一般的に可能であるということは事実ではありません。

以上がjs-framework-benchmark - 速度に関する數(shù)學(xué)的問題に対する理想的な解決策のバリエーション、またはそれが標(biāo)準(zhǔn)である理由の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語 Web サイトの他の関連記事を參照してください。