js-framework-benchmark - 速度に関する数学的問題に対する理想的な解決策のバリエーション、またはそれが標準である理由

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

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

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

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

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

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

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

テストアプリ:

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

状態が変化したときに発生する可能性のあるさまざまなキーアクションの結果が表に示されています。作業の速度を測定し、どのコードがより速く動作し、どのコードがより遅く動作するかを比較できます。これは、すべてのフレームワークとライブラリに平等な競争の場を生み出すため、非常に便利です。しかし、速度だけが問題であればいいのですが、構造そのものの基準も定められており、それが正しくなければなりません。コンポーネントのアプローチ、主要な実装、状態、その他の用語がすべてこれに含まれます。そのような標準がなければ、これは単に実用的なトピックではありません。

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

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

そうですね、このようなコミュニティは近年、現在および将来のすべてのクリエイターが現在使用できる多くのクールなソリューションを生み出してきました。基本的なアルゴリズムはすでに記述されているため、車輪を再発明する必要はありません。この理解により、多くの年月を節約できます。

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

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

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

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

以上がjs-framework-benchmark - 速度に関する数学的問題に対する理想的な解決策のバリエーション、またはそれが標準である理由の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。