Steve Souders，“JavaScript 主宰浏览器 CPU”
十年前，网络是主要瓶颈。如今，主要瓶颈是 JavaScript。页面上的 JavaScript 量正在快速增长（过去 7 年增长了近 5 倍）。为了保持页面渲染并保持快速感觉，我们需要关注 JavaScript CPU 时间以减少阻塞浏览器主线程。
Alex Russell，描述了 Chrome 中“永不缓慢模式”的原型
… 阻止大型脚本，为特定资源类型（脚本、字体、css、图像）设置预算，关闭 document.write()，覆盖同步 XHR，普遍启用客户端提示，以及缓冲未设置 Content-Length 的资源。
Craig Hockenberry，在 WebKit 错误跟踪器中发布了 一个想法
如果没有限制，JavaScript 开发人员就没有任何动力去保持其代码库小巧，并使依赖关系最小化。添加另一个框架很容易，然后该框架又添加了另一个框架，接下来你就会知道，你正在加载数兆字节的数据，仅仅是为了显示数百千字节的内容。…
我所设想的情况是，网站可以显示任何他们想要的广告，只要他们将总大小保持在固定范围内，比如每页 1 兆字节。如果他们努力使他们的网站高效，我很乐意提供我的眼球。
将手指指向框架和第三方脚本的大量 JavaScript 很容易。如果您有兴趣了解更多关于框架大小的信息，您可能会喜欢 我和 Dave 与 Jason Miller 讨论它。
说到第三方，Patrick Hulce 创建了 Third Party Web：“这份文件总结了哪些第三方脚本对当今网络上过度的 JavaScript 执行负有最大责任。”
有时，点名道姓是一种有效的策略，可以激发改变。
Addy Osmani 写了关于 一个 ESLint 规则，该规则禁止特定包，您可以使用它来防止使用已知庞大的包。因此，如果有人试图加载整个 lodash 或 moment.js，它可以在代码检查级别被阻止。
Tim Kadlec 在 “限制 JavaScript？” 中很好地将这些线索联系在一起。如果你对此的本能反应是 JavaScript 被不公平地视为反派，Tim 承认
我看到人们表达的一个普遍担忧是“如果是 JavaScript，为什么不限制其他资源呢？”。的确，JavaScript 确实经常被挑剔，但并非没有理由。就字节而言，JavaScript 是网络上性能最显著的损害，因此将重点放在减少我们使用的数量确实有意义。
然而，这一点是有效的。JavaScript 可能是最常见的罪魁祸首，但它并非唯一一个。
一个普遍被忽视的真相是，延迟比带宽更早地杀死性能。
想要证明吗？如果带宽很重要，YouTube 和 Netflix 根本不存在。
绝对没有任何东西要求每页超过 1 个 HTTP 请求。
什么？但是如果网络速度快 20 倍，这篇文章还有意义吗？我认为网络仍然是罪魁祸首。我应该能够每秒下载 1GB。为什么不呢？
嗯？不是网络。如果你以极速下载 1GB，但你的浏览器必须解开它并将元素附加到 DOM，并且可能在渲染某些元素后下载异步资源，那么下载所需的时间是最不重要的。是那些“现代”框架和模式给浏览器增加了太多负担。你实际上是在要求你的浏览器成为你的操作系统，而你的网页代码是你的应用程序。现在流行的创建大型 JavaScript “捆绑包”的方法，它是一个编译后的 JS 应用程序，只是在要求浏览器做太多的事情。对不起，伙计们。回到干净的 HTML，并从那里逐步增强。
不要把开发问题归咎于 JS。JS 是网页开发发生过的最好的事情。那么那些数百个在线课程说你在不到 2 个月的时间内就能成为网页开发人员呢？今天，我们拥有不错的浏览器、强大的处理器和廉价的内存，我们也需要不错的网页应用程序。网页应用程序是公司开发跨平台信息系统的最便宜、最有效的方式。AJAX、图表或 DOM 操作是提供功能和美观的 UX 所必需的。而我们需要 JS 来实现这一点。
说真的，我不再喜欢 JavaScript 了。就我个人而言，我尽量最小化使用它。