大家好！我花了 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 上看到資料變化的速度越快，花費(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è)依賴資料的表格。這看起來(lái)像是一個(gè)簡(jiǎn)單的任務(wù)，但事實(shí)上，它非常非常具有指示性，因?yàn)樗屓藗冏⒁獾綉?yīng)用程式可以看起來(lái)像任何東西，但是元件、它們?cè)贒OM 中的順序、與瀏覽器一起工作以及其他事情- 模仿常規(guī)網(wǎng)站的行為。因?yàn)楸砀裰械囊恍小㈨?yè)面上的標(biāo)題 - 都是一般性的，只是一般性的一個(gè)組成部分。

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

所以，我們有一個(gè)任務(wù)，但我們需要以某種方式解決它。程式設(shè)計(jì)是好的，因?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)在來(lái)看看介面，它是什麼樣的：

測(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í)作、狀態(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)題解決方案。就程式設(shè)計(jì)而言，這不是一個(gè)很好的比較，因?yàn)樗皇菙?shù)學(xué)，但這個(gè)想法本身很有趣，因?yàn)樗偈谷藗冏龅闷?、快速，最重要的是，它是正確的。

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

許多開(kāi)發(fā)人員已經(jīng)編寫(xiě)了實(shí)現(xiàn)理想程式碼的範(fà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)有了顯示資料的理想程式碼，值得考慮它並基於它做一些新的事情，而不是重新發(fā)明輪子。如今，許多函式庫(kù)和框架可以更快、更有效率地工作，只是遺留程式碼不允許這樣做，因?yàn)榭赡苄枰龊芏喙ぷ?，而且事?shí)是，通常不需要重做所有事情就可以實(shí)現(xiàn)。

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