大家好！我花了 2.5 年的時(shí)間解決了 js-framework-benchmark 存儲(chǔ)庫(kù)中的速度問(wèn)題，我并不后悔，因?yàn)槲易罱⒁獾搅艘粋€(gè)超級(jí)有趣的觀察。

基本上，所有框架和庫(kù)開(kāi)發(fā)人員在 Web 開(kāi)發(fā)的早期階段都面臨著速度問(wèn)題。這是最重要的，因?yàn)槿藗冊(cè)?UI 上看到數(shù)據(jù)變化的速度越快，他們花費(fèi)的時(shí)間就越少。想象一下，如果網(wǎng)站運(yùn)行速度提高 10%，那么數(shù)十億人就可以挽救很多年的生命。

必須做一些事情，因此，也許出于其他原因，創(chuàng)建了許多具有現(xiàn)代框架和庫(kù)基準(zhǔn)的存儲(chǔ)庫(kù)。 js-framework-benchmark 就是此類存儲(chǔ)庫(kù)之一。它包含幾乎所有用于創(chuàng)建 UI 的流行框架和庫(kù)。

主要任務(wù)是繪制一個(gè)依賴于數(shù)據(jù)的表格。這看起來(lái)像是一個(gè)簡(jiǎn)單的任務(wù)，但事實(shí)上，它非常非常具有指示性，因?yàn)樗屓藗冏⒁獾街饕氖虑椋簯?yīng)用程序可以看起來(lái)像任何東西，但是組件，它們?cè)?DOM 中的順序，與瀏覽器一起工作，并且其他事情 - 模仿常規(guī)網(wǎng)站的行為。因?yàn)楸砀裰械囊恍?、?yè)面上的標(biāo)題 - 都是一般性的，只是一般性的一個(gè)組成部分。

由于應(yīng)用程序正常工作，以代碼和時(shí)間作為依賴項(xiàng)（我們不考慮顯示、顏色，因?yàn)樗梢栽诰€路上表示為 0 和 1，因此只有 2 個(gè)這樣的依賴項(xiàng)），那么至少有一個(gè)組件，至少一百萬(wàn)個(gè)不同的相互交織的組件 - 沒(méi)有特殊的含義，因?yàn)橐磺卸家蕾囉谝粋€(gè)引擎。因此，簡(jiǎn)單在這里更合適，因?yàn)樗芮逦?/p>

所以，我們有一個(gè)任務(wù)，但我們需要以某種方式解決它。編程是好的，因?yàn)槲覀兛梢杂靡话偃f(wàn)種不同的方式解決一個(gè)數(shù)學(xué)問(wèn)題，但我們來(lái)到主要的事情，基本的理想算法對(duì)每個(gè)人來(lái)說(shuō)都是相同的。這是一個(gè)定理，實(shí)現(xiàn)什么以及如何實(shí)現(xiàn)取決于品味和方便性的需要。

我們現(xiàn)在看一下界面，它是什么樣的：

測(cè)試應(yīng)用程序：

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

我們有狀態(tài)更改時(shí)可能發(fā)生的表中不同關(guān)鍵操作的結(jié)果。我們可以測(cè)量工作速度并比較哪些代碼運(yùn)行得更快，哪些代碼運(yùn)行得更慢。這非常方便，因?yàn)樗鼮樗锌蚣芎蛶?kù)創(chuàng)建了一個(gè)公平的競(jìng)爭(zhēng)環(huán)境。不過(guò)如果只是速度問(wèn)題就好了，但是結(jié)構(gòu)本身的標(biāo)準(zhǔn)也定下來(lái)了，因?yàn)樗仨毷钦_的。組件方法、關(guān)鍵實(shí)現(xiàn)、狀態(tài)和其他術(shù)語(yǔ)都包含在其中。如果沒(méi)有這樣的標(biāo)準(zhǔn)，這根本就不是一個(gè)可行的話題。

因此，該標(biāo)準(zhǔn)長(zhǎng)期以來(lái)都是由框架和庫(kù)的創(chuàng)建者制定的 - 對(duì)于那些這樣做的人來(lái)說(shuō)，這是顯而易見(jiàn)且可以理解的。問(wèn)題是，現(xiàn)在我們需要以某種方式適應(yīng)所有這些以實(shí)現(xiàn)快速工作，以便快速渲染 UI。

所以，聚集所有“大型”和不太大型框架和庫(kù)的創(chuàng)建者，以及也想嘗試一下的愛(ài)好者，這是一個(gè)很酷的想法。所有這些都很重要，因?yàn)榫拖裨隗w育運(yùn)動(dòng)中一樣，我們有一個(gè)社區(qū)，并且有一個(gè)“領(lǐng)導(dǎo)者”委員會(huì)，其中發(fā)布了不同的問(wèn)題解決方案。就編程而言，這不是一個(gè)很好的比較，因?yàn)樗皇菙?shù)學(xué)，但這個(gè)想法本身很有趣，因?yàn)樗偈谷藗冏龅闷?、快速，最重要的是，它是正確的。

嗯，這樣的社區(qū)近年來(lái)產(chǎn)生了許多很酷的解決方案，今天和未來(lái)的所有創(chuàng)作者都可以使用這些解決方案。你不必重新發(fā)明輪子，因?yàn)榛舅惴ㄒ呀?jīng)寫(xiě)好了。這種理解可以節(jié)省很多年。

許多開(kāi)發(fā)人員已經(jīng)編寫(xiě)了實(shí)現(xiàn)理想代碼的示例，基于此非常容易，所以最好的事情是，這種情況以前沒(méi)有發(fā)生過(guò)，而且它發(fā)生了，除其他外，因?yàn)檫@個(gè)存儲(chǔ)庫(kù)。不管別人怎么說(shuō)，都很酷。

如果我們按組件考慮理想算法，我們可以突出顯示 - 關(guān)鍵實(shí)現(xiàn)的算法（使用最長(zhǎng)遞增子序列或其其他變體）、模板克隆、直接反應(yīng)性（textContent、addEventListener、classList.add），或今天使用無(wú)用的 VDOM，盡管就模板而言它是必要的，以及處理組件之間的狀態(tài)和導(dǎo)入，最后兩個(gè)是值得商榷的。但這就是基礎(chǔ)，這里不能再發(fā)明別的了。

本文不會(huì)包含任何此類代碼，因?yàn)榛鶞?zhǔn)存儲(chǔ)庫(kù)中有很多這樣的代碼。

無(wú)論如何，我希望人們很快就會(huì)明白，今天我們已經(jīng)有了顯示數(shù)據(jù)的理想代碼，值得考慮它并基于它做一些新的事情，而不是重新發(fā)明輪子。如今，許多庫(kù)和框架可以更快、更高效地工作，只是遺留代碼不允許這樣做，因?yàn)榭赡苄枰龊芏喙ぷ?，而且事?shí)是，通常不需要重做所有事情就可以實(shí)現(xiàn)。

以上是js-framework-benchmark - 速度數(shù)學(xué)問(wèn)題的理想解決方案的變體或?yàn)槭裁此菢?biāo)準(zhǔn)的的詳細(xì)內(nèi)容。更多信息請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！