我认为存在一些挑战因为它

rmruhul

们变得必须不断更新和维护。因此，我希望尽可能保持精简，但我认为构建工具可以让您（开发人员）花费更多的运行时间，从而减少向浏览器的交付，这是一件好事，特别是当我们构建变得更加复杂。所以我不知道我是否一定会说这只是默认的危险信号。我认为这很大程度上取决于你如何使用它。如果您需要运行构建来发布一页或两页的营销网站或宣传册网站，是的，这是一个危险信号。但是，如果您正在构建一些复杂的应用程序，并且这些应用程序允许您以对您来说更有意义的方式进行创作，然后向浏览器发送更少的内容，那么这并不是一件坏事。这就是为什么我发现像 ASTRO 这样的工具真的非常非常有趣，因为那里仍然有一个构建步骤，但它是提供更好的最终用户体验的服务的构建步骤。

德鲁：是的。它将所有计算转移到服务器上以构建时间或预延迟时间，而不是页面请求时间。

克里斯：是的。因此，对我来说，我几乎将构建步骤分解为……就像对 电报号码数据 我来说，黄金标准是如果我可以在没有任何构建步骤的情况下交付它，那就太棒了。但即使对我自己来说，这个香草爵士乐手也不是百分百今天做事的方式。因此，我认为下一步是编译器将代码减少为尽可能多的 HTML 和普通的旧 JavaScript，而不是那些创建更多 JavaScript 的编译器，比如那些使用一堆小文件并生成更大文件的编译器。因此，如果可能的话，多一点前者，少一点后者总是一件好事，但并不总是可能。

德鲁：我认为，脱离依赖跑步机，对于 Vanilla JavaScript 方法来说，它一定是一个很大的吸引力，因为没有一百万个依赖项需要一直更新，但我想这是一些更大框架的优势之一是他们有时规定、有时促进统一的工作方式，这对于大型团队来说非常重要。如果没有框架规定的标准和程序，项目是否会有偏离轨道的危险？

克里斯：是的。是的。我认为这是公平的。我想，我曾经一度淡化了这一点的重要性。我认为这是有效的。这是这些工具的一个公平的好处。我认为，也许这里的一个小反驳是，如果你谷歌“如何用 React 做 X”，你会得到六种不同的方法来完成这件事。所以有约定，但不一定是硬性规定，就像如果你不这样做，一切都会违反某种规则。这些工具的吸引力之一是它们具有很大的灵活性。当然，他们确实执行了更多标准方法，但不仅仅是浏览器本机所做的绿色领域。因此，我认为即使没有强有力的团队领导来推动内部代码标准，也可能存在一定的平衡。



克里斯我以前见过甚至基于框架的项目也以大杂烩的方式脱轨。因此，这些工具不会自动为您提供这些信息，但它们肯定会为您提供一些指导，也许是一些引导您走向正确方向的轨道。我知道有些人需要这个。如果这是您需要的，这就是我真正喜欢的地方，我们看到更多使用相同约定的较小库，例如 Petite Vue 或 Preact 以及编译器……就像 FELT 一样，当然有一些非常严格的规范比你在 ASTRO 中看到的更多，所以如果你真的需要它，我认为你有一些选择，不会像我们几年前所做的那样惩罚用户的这种需求。

德鲁：在我所做的工作中，我们使用 Vue，Vue 单文件组件是一个非常引人注目的案例，因为我们有工程师编写前端代码，他们不一定是前端专家，他们说这是一种创建方法一个骨架单文件组件。您的模板位于此处，您的 Java 脚本位于此处，您的 CSS 位于此处。很自然地，我们最终得到了一个非常一致的代码库，尽管它是由非常不同的人创建的。因此，这样的惯例确实可以为那些不一定都朝着同一个方向前进的团队带来很大的好处，因为工程部门太大了或者其他什么原因。