对我来说我几乎将构建

rmamin

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

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

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

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



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

克里斯：耶，当然了。我认为你有时会遇到麻烦……我同意。我非常喜欢使代码库看起来与一群不同的人在处理它时保持一致的能力，这真的非常重要，因为今天编写代码的人不一定是以后维护它的人。这很快就会变得混乱。另一方面是，如果您不太熟悉或不太精通 JavaScript，那么许多现代工具集实际上都是针对 JavaScript 的。团队中有很多人主要专注于 HTML 或 CSS 或可访问性。对于他们来说，JavaScript 不是核心能力，我认为期望它成为核心能力也不公平。就像您不期望所有 JavaScript 开发人员都是 CSS 专家一样。