这是 Julia Evans 写的一篇很棒的文章，关于与现代前端工具的较量。Julia 创建了许多 Vue 项目，并且通常根本不使用构建过程
我通常会有一个
index.html文件，一个script.js文件，然后我会使用<script src="script.js">，就是这样。
我认为这很棒，并且可能意味着这些项目将持续很长时间。但是，我理解人们希望转向一些更现代的开发工具，即使只是为了解锁整个 npm 生态系统。基本上，Julia 想做
import Vue from 'vue';这直接意味着 npm 和打包器，因为这种语法是打包器特定的（它是无效的 ES 模块语法）。这过去几乎意味着 webpack、rollup 或 Parcel，但这种情况正在开始改变，并且 强烈建议使用 Vite。
但 Julia 不想使用功能过于强大的工具（）
但我停止使用这些工具，并回到了我旧的
<script src="script.js">系统，因为我不理解vue-cli-service和vite在做什么，并且我不确定自己是否能够在它们出现故障时修复它们。所以我宁愿坚持使用我真正理解的设置。
因此，由于 Vite 功能过于强大，Julia 选择了 esbuild。我不能说我完全理解细节，但 Vite 在内部使用 esbuild 来完成某些事情
Vite 使用 esbuild 而不是 Rollup 来进行依赖项预打包。这在冷服务器启动和依赖项失效时的重新打包方面带来了显著的性能提升。
因此，直接使用 esbuild 算是在复杂度阶梯上向下走了一步。
它非常接近于完美，但当然，前端生态系统的复杂本质再次出现了。esbuild 从 import Vue from 'vue'; 中获取的 Vue 的假设副本是 vue.runtime.esm.js，它是为在浏览器中运行而设计的 Vue 版本，而不是包含编译器的版本。Ughghk。感觉它们应该是两个独立的包或类似的东西。但 Julia 最终克服了这个问题，并且取得了胜利
我不理解 esbuild 做的所有事情，但它感觉比我以前使用过的基于 [webpack] 的工具更易于理解和透明。
所有这些都是我仍然看好 Skypack 的另一个原因。您可以 使用像这样的现代 import 语句，并且仍然不需要任何构建过程。
一个小小的修正（在一个我过去几年里变得非常熟悉的领域）
这并不完全正确。事实上，它完全是有效的 ES 模块语法，因为 ES 规范将 import 语句的字符串标识符部分定义为实现可以自由定义的内容。所以
Node 12 LTS 附带的 Node ESM 支持完全符合规范。
Ember 的经典自定义模块解析方案也是如此（正在逐渐被淘汰，转而支持与 Node 兼容的解析）。
Deno 的基于 URL 的方案也是如此。
还有（这是这里的重要部分）浏览器已经采用的要求 URL 的标准。
这是一个小细节，但提出了我认为很重要的一点。有时人们倾向于将浏览器所做的事情视为定义什么是规范和不是规范。这其中有一定道理，因为它们通常是帮助定义规范的最强音之一：但与 CSS 不同，JavaScript 不是浏览器唯一定义的东西。
在这里，网络上的情况是，该代码片段至少在今天暗示了一个非浏览器环境，因为浏览器选择要求 URL，并且没有为标准库实现模块。将来，这种情况可能会发生变化。然后，可能可以编写 import 语句（在浏览器的
script标签中！），而不是一直将内容挂在全局名称上（Number.isNaN()）。（据我所知，目前还没有关于此的提案，但这是一个好主意，并且已经讨论过，它有助于说明这一点。）
裸模块说明符可以通过导入映射在浏览器中得到支持。但是，生成导入映射的合理方法将依赖于构建步骤。
带有内置命名空间/对象的标准库的裸说明符也很有趣，但我认为导入映射中没有涵盖这一点。
是的，我只需要一些东西来获取文件的哈希值，并将它们插入并更改文件名。但是没有工具可以做到这一点，而无需执行更多操作。也许有些工具可以做到这一点。但我还没有找到。
如果它还可以转译我的 TypeScript 文件就好了。但仅仅是前者就足够好了。