面临的挑战在将整个东西

rmruhul

解压到实际的代码波之和之间的差异是 27 KB。仅原始下载、解包和编译时间就会给 UI 上的初始负载增加相当多的延迟。如果您的用户使用的不是 Apple 的最新设备，这种情况会变得更加明显。即使是几年前的 Android 设备或功能手机，或者如果你的用户生活在发展中国家，也确实……启动时间会更慢。最重要的是，由于额外的抽象，实际的交互时间会变慢。

克里斯：因此，不仅仅是您加载它，它们的速度也相当。由于其中存在所有额外的代码，某人进行的每次微交互以及需要发生的更改也可能会稍微慢一些。如果您有一个非常非常复杂的 UI，其中包含大量嵌套元素和大 电报号码数据 量数据，那么虚拟 DOM 的性能提升将超过额外的代码重量。但是，对于我所看到的大多数开发人员使用 React 或 Vue 的典型应用程序的任何典型 UI，您从虚拟 DOM 中获得的好处并不存在，而且他们的情况会更好。即使您想保持 React 的便利性，也可以使用 Preact。它的大小只是其一小部分，但工作方式完全相同，而且性能更高。这是我倾向于争论的事情。

克里斯：我们需要更好地为工作选择合适的工具。如果你采用这样的方法，如果你达到了虚拟 DOM 真正有意义的地步，那么将 Preact 移植到 React 中比你自己推出要容易得多。情况就是这样。如果您真的担心这一点，您还可以获得一些内置的面向未来的功能。

德鲁：有些人可能会说，他们可能会争论说，这些框架（例如 Vue、React）对于性能进行了高度优化，因此您可以从中获得很多好处，因此只需将其与捆绑器中的包管理器配对即可确保您只是发送您想要的代码。当然，仅仅这样做你就已经领先了？

克里斯：是的。我不同意。除了……我想也许是，但不是真的，我真的没有更多的东西可以详细阐述。即使使用捆绑器，您仍然需要 React 核心。即使进行捆绑，这仍然比使用 Preact 之类的东西更大。



克里斯德鲁我真的很感谢你提出这个问题。因为我在我的书《精益网络》和我的同名演讲中谈论的其他事情之一是这些工具如何......例如，您提到了捆绑。为了解决使用所有这些 JavaScript 所带来的性能损失，我们所做的一件事就是在前端添加更多的 JavaScript 来解决这个问题。我们做到这一点的方法之一是包管理器和模块捆绑器。

克里斯：正如您提到的……对于那些不知道的人来说，这些工具将……它们会将您所有的小型 JavaScript 代码编译成一个大文件。更新的和更多的……我不想称它们是深思熟虑的。但较新的将使用一种称为树摇动的功能，它们会删除任何实际不需要的代码。如果该代码具有一些未用于您实际完成的操作的依赖项，它们会删除其中的一些内容以使您的包尽可能小。这实际上并不是一个可怕的想法，但它会导致这种情况，我通常称之为依赖关系健康，在这种情况下，你会在依赖关系之上拥有一个非常微妙的依赖关系卡片。

克里斯：设置流程需要时间。任何曾经运行过 NPM 安装然后发现一堆依赖项已经过时的人都必须花一个小时尝试找出哪些依赖项需要修复，哦，这实际上是依赖项中的依赖项，而您不这样做没有能力自己去修理。这是一整件事。也许它对你有用，但我宁愿花时间不要浪费时间尝试将我的依赖项放在一起。