然后我看到的第二个趋势

rmruhul

个人认为更引人注目是从库到编译器的转变。因此，里奇·哈里斯（Rich Harris）感受到了推动这一整个趋势的因素，他采用了基于状态的反应性的想法。但是，您不必让它在客户端中实时运行，而是使用与 React 或 Vue 相同的通用模式来编写代码，然后运行一个构建工具，将所有这些编译为简单的旧 HTML 并vanilla JavaScript，这就是发送到浏览器的内容。因此，您已经剥离了客户端中的几乎所有抽象，并且您提供的内容更接近您使用旧式 DOM 操作手写的内容，但具有基于状态的 EI 为开发人员带来的便利。这真的很有趣。

克里斯：最近有一个名为 ASTRO 的新工具，它建立在 Rich 使用 Svelt 的基 电报号码数据 础上，还允许您从您最喜欢的库中提取组件，以便您可以混合和匹配 Vue、React、FELT、Vanilla、JavaScript，所有这些都在一个包中，将其全部编译为 Vanilla JavaScript 并交付数量级的代码，无需抽象即可减少代码量。因此它在浏览器中的运行速度也会更快。我认为对我来说，这确实是两件大事，就像站在巨人的肩膀上并生产出有望开始变得更快一点的前端。编译器特别有趣，因为它们使我们尽可能远离在浏览器中渲染 HTML。您仍然可以渲染 HTML，或者如果需要，您仍然可以使用 JavaScript 进行编写，但输出的结果是更多静态 HTML 和更少 JavaScript，这始终是一件好事。

德鲁：您认为这是生态系统对开发人员对现代框架的重量的悄悄不满的回应吗？这只是自然的起伏吗？

克里斯：是啊，就是。尽管说实话，我并不完全确定这在多大程度上是由……驱动的……嗯，肯定有一些注重性能的开发人员，他们一直直言不讳地指出这些工具对用户来说是如何不利的。但我不知道这是否一定能代表一般人群。我的意思是，考虑到我们上次谈论这一集的情况，当然是其中的一个子集，但我认为这些工具对我来说都没有达到的目的之一是......或者是我最受现代困扰的事情我认为这些工具没有解决的问题是，我个人觉得一般的开发过程过于复杂。




克里斯这就是我进入整体的地方，我不认为使用这些工具的开发人员体验实际上更好，但我认为对于团队环境中的许多开发人员来说，它可以是更好的。对于我来说，作为一个主要的独立开发人员，我发现这些工具比它们的价值更麻烦，但我知道很多人不同意我的观点，所以我不想认为这是无效的。如果您发现这些工具非常有用，但是是的，我认为这可能是一个自然的钟摆向另一个方向摆动。

克里斯：我没有谈论的第三件事是，你的问题实际上让我思考，网络中几乎存在一个自然循环，你开始投入大量 JavaScript 来解决网络及其功能的问题。生长。最终这些 JavaScript 库会被平台本身吸收，但这个过程比创建新的 JavaScript 库要慢得多，因为它是标准流程，而且这些流程非常重要。所以我们看到同样的事情发生在 jQuery 上，对吧，随着 jQuery 和 jQuery 插件的出现，网络上使用的 JavaScript 数量不断增加。

克里斯：最终，网络平台意识到这些做事方式非常聪明，我们开始采用原生方式来做到这一点。然后，对 jQuery 的转变经历了一段漫长而缓慢的过程。所以我认为这些图书馆，尽管他们做了很多……这会有点争议，他们对网络造成了很大的损害。它们还在为原生 API 的功能铺平道路方面发挥了重要作用。所以我不想完全认为它们很糟糕。