2020年：前端开发的痛苦与快乐不久之前

文章插图
不久之前，我开始为自己的新项目构建一套仪表板。这套仪表板中包含一个 Node.js API 网关（仍处于起步阶段），外加用于记录的 Clickhouse：
这就引出了本文的主题：很多朋友可能没有意识到，膨胀已经成为前端世界中的头号难题。转译器、捆绑器、编译器再加上观察器，负责在保存过程中对项目进行重新编译、在浏览器中进行热重载，而这一切都让普通 JavaScript 开发者陷入了无穷无尽的苦难当中。
下面我为大家列出一份与 Vue 相关的项目清单，正是它们给我过去半年里的开发工作带来诸多麻烦（全部使用 15 英寸与 16 英寸 MacBook Pro 设备）：
Nuxt
【2020年：前端开发的痛苦与快乐】启动器应用的可调整空间太小，让 Macbook 用户们感到头痛不已。浏览器会不断进行热重载， GitHub 上的 Nuxt 项目问题队列中有很多评论都指向这方面内容。
Vuestic Dashboard
我其实很喜欢这款 Vue 仪表板的设计与细节，因此打算稍作调整用在自己的项目里。在 Docker 中（Macbook Pro 16 英寸），它的开发者模式启动时长经常会超过 2 分钟，而 com.docker.hyperkit 显示 CPU 占用率达 400% 。考虑到设备中只有 4 GB 内存专供 Docker 使用，可以想见它在这台 Macbook Pro 上根本无法构建生产版本的文件。很明显，它应该想办法使用 6 GB 内存外加“指派”存储卷进行 Docker 设置，目前我已经根据 VS Code 说明文档的指示完成了这项调整：
#_update-the-mount-consistency-to-delegated-for-macos
但即使是在开发者模式下保存文件这么一项简单操作，也仍然需要至少 10 秒钟才能完成。
为什么？
Docker 开发环境的出现，极大提高了 JavaScript 阵营的整体实力。
据我了解，当大家将主机操作系统文件夹绑定至 Docker 存储卷时，我们实际上无法在某些 JS 项目中保存某些文件，这就导致有相当一部分文件需要使用 Chokidar 或者类似的库进行重新编译，这种未经优化的垃圾堆会极大占用硬件资源。虽然这一切与生产构建无关，但单是编译器与捆绑器就足够让 Macbook 和开发者忙得焦头烂额了。
如果大家每天只需要面对一个 JS/TS 项目，而且压根不用 Docker、只在自己的主机操作系统上进行开发的朋友来说，这可能不是什么大问题。但对于面对完整开发栈的群体，以上问题就根本无法接受了。跟我一样，许许多多开发者都喜欢 VS Code Containers 项目，但这种喜爱也成为我们痛苦的根源。
没错， Docker 本身也有问题，但至少在最近 2、3 年中，它已经成为我在开发工作中的必选项目。这次之所以要使用 VS Code Containers 加 Docker 进行开发，是因为这套组合在便利性、灵活性与强大的可重现性方面简直无可匹敌。
解决方案: esbuild
esbuild 是另一款 JavaScript 捆绑器与缩小器。下面来看看它的强大能力。
闲言少叙，咱们用图说话：
文章插图
这是怎么做到的？

它使用 Go 语言编写而成， Go 语言可以编译为原生代码；
解析、输出与源映射生成完全以并行化方式进行；
不涉及资源成本高昂的数据转换，只需要很少几步即可完成所有操作。

对于像我这样绝望的开发者来说，它的效果实在是太棒了。更重要的是， Vue 3 在其 Vite 捆绑器中内置 esbuild ，所以我意识到要想摆脱痛苦的生活，我得马上转移到 Vue 3 加 ESM 这片阵地上。
我将 vuestic 替换成了 v-dashboard ，其使用 Vue 3 与 Tailwind 。为此，我得做好学习新技术的准备：

Tailwind；
ES 模块工作原理；
Vue 3 Composition API 及其所有特性；
了解在哪里能够获得 Axios 的 ESM 版本以及所有相关内容；
摆脱尚未全面支持 Vue 3 的 vue-chartjs ，转而适应 Chart.js 。

但在看到 Vite 在编译新仪表板时的出色表现，我发现一切都物有所值。
Vite 的提速原理Vite 使用 ES 模块加 esbuild 带来了极快的处理速度。具体的提速原理就是之前提到的那三点。
ES 模块
它其实就是我们的老朋友 Typescript 中的“import”语句。现在您已经可以在各种浏览器中直接使用，赞！
这项功能还无法支持所有网络浏览器，也许还要再等一年才能全面普及。但它已经可以在最新的 Chrome 与 Firefox 中正常使用，因此大家不妨考虑将其引入开发当中。