因为我通常使用慢速应用程序

mdruhul

他们的经验是，大型 React 应用程序可能非常慢，并且可能对性能非常有害。对于所有事情，可能都取决于你在做什么。但深入探讨后，有没有办法判断您的使用对性能有利还是不利？

伊万·阿库洛夫：老实说，这是个好问题。我没听说过案例。这可能完全是我的观点存在偏差，而不是快速应用程序。但老实说，我还没有听说过人们会转向 React 的案例，因为它比原来的方法更快。人们肯定会进行切换，因为打开两次更方便，或者因为更容易编写可维护的代码，或者因为生态系统更大，或者类似的原因。但我听说过因为速度更快而进行切换的案例。

伊万·阿库洛夫：实际上，速度是 React 创建时大力提倡的一个东西，就像 土耳其 WhatsApp 号码列表 整个团队，（？）等等。但是 React，在引入该模式几年后，React 抛弃了它，因为他们以自己为导向关于开发经验。我实际上不确定他们对自己的兴趣是什么，但我记得他们放弃这个模型是非常具体的事情，因为这不再是人们购买 React 的目的。

德鲁·麦克莱伦：很可能，React 总是会比传统的慢一点，但它在开发人员体验和可维护代码方面也有很多优点。

伊万·阿库洛夫：我想是的。杰夫·爱德华兹（Jeff Edwards）有一篇很棒的文章，叫做“我们的成功之坑”或类似的东西。在文章中，他提到编程语言和生态系统有一个成功的坑。比如C++有一个成功的坑，或者内存问题的一个绝望的坑。每当你用 C++ 编写代码时，编写一些直接内存访问的代码是非常容易的，但它们会引入一些错误、漏洞或其他什么。

伊万·阿库洛夫：你必须不断思考，你必须不断思考，以确保你编写的代码不会引入内存问题，引入内存错误。我认为JavaScript，是成功的唯一深坑，还是绝望的深渊。JavaScript 和 React 系统有很多好处。再说一遍，这是可维护性，这是我们谈论的一切。



伊万·阿库洛夫：我认为绝望的深渊是一个很容易掉入的陷阱，除非你积极思考，并且除非你积极防止自己陷入其中，否则你会制作出一个加载性能变慢的应用程序。因为安装一些 NPM 依赖项并将其导入捆绑包并将其分成 100 KB 或 185 KB 的捆绑包太容易了。或者就返回性能而言，因为创建一个会随着时间的推移而呈现并以太多代码或其他方式运行的组件太容易了。

德鲁·麦克莱伦：大约一年前，我第一次看到你的作品，当时你发布了一个分析概念页面性能的案例研究。我想我们都喜欢 Notion，而且可能没有人不希望它更快。别以为这不是有报酬的工作，是吗？这只是一次教育活动？

伊万·阿库洛夫：是的。有时，当我有时间尝试为一些热门网站进行案例研究时，我非常喜欢这样做。对于任何认为有用的人来说，这也是很好的教育材料。