js-framework-benchmark - 速度数学问题的理想解决方案的变体或为什么它是标准的

大家好！我花了 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中文网其他相关文章！