2020年:前端开发的痛苦与快乐

2020-11-05 20:17:19 浏览数 (1)

作者 | Anton Sidashin

译者 | 核子可乐

策划 | 田晓旭

不久之前,我开始为自己的新项目构建一套仪表板。这套仪表板中包含一个 Node.js API 网关(仍处于起步阶段),外加用于记录的 Clickhouse:

https://github.com/restyler/api-gateway

这就引出了本文的主题:很多朋友可能没有意识到,膨胀已经成为前端世界中的头号难题。转译器、捆绑器、编译器再加上观察器,负责在保存过程中对项目进行重新编译、在浏览器中进行热重载,而这一切都让普通 JavaScript 开发者陷入了无穷无尽的苦难当中。

下面我为大家列出一份与 Vue 相关的项目清单,正是它们给我过去半年里的开发工作带来诸多麻烦(全部使用 15 英寸与 16 英寸 MacBook Pro 设备):

Nuxt

https://nuxtjs.org/

启动器应用的可调整空间太小,让 Macbook 用户们感到头痛不已。浏览器会不断进行热重载,GitHub 上的 Nuxt 项目问题队列中有很多评论都指向这方面内容。

Vuestic Dashboard

https://github.com/epicmaxco/vuestic-admin

我其实很喜欢这款 Vue 仪表板的设计与细节,因此打算稍作调整用在自己的项目里。在 Docker 中(Macbook Pro 16 英寸),它的开发者模式启动时长经常会超过 2 分钟,而 com.docker.hyperkit 显示 CPU 占用率达 400%。考虑到设备中只有 4 GB 内存专供 Docker 使用,可以想见它在这台 Macbook Pro 上根本无法构建生产版本的文件。很明显,它应该想办法使用 6 GB 内存外加“指派”存储卷进行 Docker 设置,目前我已经根据 VS Code 说明文档的指示完成了这项调整:

https://code.visualstudio.com/docs/remote/containers-advanced#_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

https://github.com/evanw/esbuild

esbuild 是另一款 JavaScript 捆绑器与缩小器。下面来看看它的强大能力。

闲言少叙,咱们用图说话:

这是怎么做到的?

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

对于像我这样绝望的开发者来说,它的效果实在是太棒了。更重要的是,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”语句。现在您已经可以在各种浏览器中直接使用,赞!

https://kentcdodds.com/blog/super-simple-start-to-es-modules-in-the-browser

这项功能还无法支持所有网络浏览器,也许还要再等一年才能全面普及。但它已经可以在最新的 Chrome 与 Firefox 中正常使用,因此大家不妨考虑将其引入开发当中。

Vite 会聪明地在适当的地方“偷工减料”,而且不需要把 JS 文件捆绑到开发 build 当中。

目前只有一个问题,esbuild 无法在编译过程中验证 Typescript 的正确性,但考虑到 VS Code 与 lang server 已经完成了验证工作,所以应该没什么关系。

结 果

  • 与之前一样,我在开发中会使用.vue 单个文件组件与 Typescript。
  • 开发启动瞬时完成,Docker 的 CPU 负载为零,热重载同样可以瞬间搞定。
  • 使用 axios、chart.js、高强度 toast 库以及简单的状态存储管理等元素时,相关内容的生产级构建大概需要 20 秒——与 vuestic 相比,这简直是种巨大的转变!

就这样,我的日常前端开发体验又回归了正常范围。这里建议大家在新项目中尝试使用 Vite(如果您更倾向于 React 或其他框架,也可以尝试使用 ES 模块 esbuild)。它虽然还不完美,仍处于 beta 测试阶段,但开发者的体验非常重要。Vite,绝对值得一个机会!

延伸阅读

https://pixeljets.com/blog/frontend-dev-gets-better/

0 人点赞