大家好！我花了 2.5 年的時間解決了 js-framework-benchmark 儲存庫中的速度問題，我並不後悔，因為我最近注意到了一個超級有趣的觀察。
基本上，所有框架和函式庫開發人員在 Web 開發的早期階段都面臨著速度問題。這是最重要的，因為人們在 UI 上看到資料變化的速度越快，花費的時間就越少。想像一下，如果網站運作速度提高 10%，那麼數十億人就可以挽救很多年的生命。
必須做一些事情，因此，也許出於其他原因，創建了許多具有現代框架和庫基準的儲存庫。 js-framework-benchmark 就是這類儲存庫之一。它包含幾乎所有用於創建 UI 的流行框架和庫。
主要任務是繪製一個依賴資料的表格。這看起來像是一個簡單的任務，但事實上，它非常非常具有指示性，因為它讓人們注意到應用程式可以看起來像任何東西，但是元件、它們在DOM 中的順序、與瀏覽器一起工作以及其他事情- 模仿常規網站的行為。因為表格中的一行、頁面上的標題 - 都是一般性的，只是一般性的一個組成部分。
由於應用程式正常運作，以程式碼和時間作為依賴項（我們不考慮顯示、顏色，因為它可以在線上表示為0 和1，因此只有2 個這樣的依賴項），那麼至少有一個元件，至少一百萬個不同的相互交織的組件- 沒有特殊的含義，因為一切都依賴於一個引擎。因此，簡單在這裡更合適，因為它很清晰。
所以，我們有一個任務，但我們需要以某種方式解決它。程式設計是好的，因為我們可以用一百萬種不同的方式解決一個數學問題，但我們來到主要的事情，基本的理想演算法對每個人來說都是相同的。這是一個定理，實現什麼以及如何實現取決於品味和方便性的需要。
我們現在來看看介面，它是什麼樣的：
測試應用程式：
部分結果：
https://krausest.github.io/js-framework-benchmark/2024/table_chrome_130.0.6723.58.html
我們有狀態變更時可能發生的表中不同關鍵操作的結果。我們可以測量工作速度並比較哪些程式碼運行得更快，哪些程式碼運行得更慢。這非常方便，因為它為所有框架和庫創建了一個公平的競爭環境。不過如果只是速度問題就好了，但是結構本身的標準也都定下來了，因為它必須是正確的。元件方法、關鍵實作、狀態和其他術語都包含在其中。如果沒有這樣的標準，這根本就不是一個可行的話題。
因此，該標準長期以來都是由框架和庫的創建者制定的 - 對於那些這樣做的人來說，這是顯而易見且可以理解的。問題是，現在我們需要以某種方式適應所有這些以實現快速工作，以便快速渲染 UI。
所以，聚集所有「大型」和不太大型框架和庫的創建者，以及也想嘗試一下的愛好者，這是一個很酷的想法。所有這些都很重要，因為就像在體育運動中一樣，我們有一個社區，並且有一個「領導者」委員會，其中發布了不同的問題解決方案。就程式設計而言，這不是一個很好的比較，因為它只是數學，但這個想法本身很有趣，因為它促使人們做得漂亮、快速，最重要的是，它是正確的。
嗯，這樣的社群近年來產生了許多很酷的解決方案，今天和未來的所有創作者都可以使用這些解決方案。你不必重新發明輪子，因為基本演算法已經寫好了。這種理解可以節省很多年。
許多開發人員已經編寫了實現理想程式碼的範例，基於此非常容易，所以最好的事情是，這種情況以前沒有發生過，而且它發生了，除其他外，因為這個儲存庫。不管別人怎麼說，很酷。
如果我們按組件考慮理想演算法，我們可以突出顯示- 關鍵實現的演算法（使用最長遞增子序列或其其他變體）、模板克隆、直接反應性（textContent、addEventListener、classList.add），或今天使用無用的VDOM，儘管就模板而言它是必要的，以及處理組件之間的狀態和導入，最後兩個是值得商榷的。但這就是基礎，這裡不能再發明別的了。
本文不會包含任何此類程式碼，因為基準儲存庫中有很多這樣的程式碼。
無論如何，我希望人們很快就會明白，今天我們已經有了顯示資料的理想程式碼，值得考慮它並基於它做一些新的事情，而不是重新發明輪子。如今，許多函式庫和框架可以更快、更有效率地工作，只是遺留程式碼不允許這樣做，因為可能需要做很多工作，而且事實是，通常不需要重做所有事情就可以實現。
以上是js-framework-benchmark - 速度數學問題的理想解決方案的變體或為什麼它是標準的的詳細內容。更多資訊請關注PHP中文網其他相關文章！
