Nuxt.js 和 Vue 使用报告

使用报告系列来到 Nuxt.js 和 Vue 啦！稍微谈谈使用感受和与 Next.js 和 React 的对比。

Vue

Vue 将代码部分 <template> 和 <script> 分开，这一点与 React 的 JSX/TSX 不同，完全写在 JavaScript/TypeScript 文件里，而 Vue 为了实现这种写法，单独创立了 .vue 文件格式。

我先谈谈 <template> 的优点吧 —— 在使用如 Nuxt UI 这种组件库时，能使用如 <template header> 这样的插槽语法，对于页面的布局，是非常方便的。相比之下，React 就需要结合使用 CSS 来实现类似的布局，然而 CSS 嘛…… 我是很难写懂的。

此外扯一点 Edge 和 Chrome 浏览器的开发者工具，对于 CSS 样式的问题排查，支持真的实在是太差劲了。某个元素的样式为什么不生效，它只置灰，但完全不会告诉你原因。据说 Firefox 的开发者工具做得更好一些，虽然我没有亲自使用过。

<script> 部分的代码和 React 的写法差不多，都是 JavaScript/TypeScript 代码，状态管理也差不多 —— 现在的很多大前端框架都在向函数式组件和 Hooks 这种写法靠拢了，Vue 也不例外。就是组合起来，可能会出现某些问题，比如重复渲染、死循环等。就我最近工作上参与的同一家公司的两个项目而言，会出现 Ctrl + S 保存后，热更新的页面失去状态，且无法再向后端发起 HTTP 请求的问题。我大致猜测是它把某些状态放在了某个组件里，在热更新时重置了这个组件的状态，导致整个页面的状态丢失。

此外实际上还有 <style> 部分，但我并不认为这是好的写法，我还是觉得样式离组件应该越近越好，也就是，应该使用 Tailwind CSS 这种写法，直接在 <template> 里写样式。

需要吐槽的地方来了。

一是组件的属性通常定义在 <script> 里的 defineProps 中。虽然 IDE 能提供提示，但如果只是打开源码阅读，还是得先找到 defineProps 的位置，才能知道这个组件到底有哪些属性。尤其是组件代码比较长的时候，经常需要来回滚动查找。

此外，Vue 本身其实也需要导入组件，只不过很多项目都会使用自动导入方案，例如 Nuxt.js 或各种组件自动注册插件。这样一来，模板里确实可以直接写组件名，不用手动写 import。但代价是组件名称往往和文件名、目录结构绑定得比较紧。重命名组件时，经常需要同步调整文件名；遇到名称冲突时，也往往要通过修改文件名或目录结构来解决。相比之下，React 更倾向于显式导入和导出，组件名称与文件名没有那么强的关联，在重构时通常会更灵活一些。

Nuxt.js

这么好框架，我非常喜欢。它和 Next.js 非常相似，因此好处什么的我也不多说。

但我此外还得多说说它的模块系统，Nuxt.js 的模块系统非常强大，提供了很多官方和第三方的模块，可以轻松地集成各种功能，比如认证、国际化、PWA 支持等等。这样的生态，Next.js 是没有的。

就它的 Nuxt Content 模块而言，是最触动我的一点。Next.js 还得结合 Contentlayer 这种第三方库来实现类似的功能 —— 注意，官方确实支持 SSG，但并没有提供一个专门的内容管理系统来处理 Markdown 文件等内容资源。

现在 note-of-me.top 的博客使用的是 VitePress，但如果以后想要对标 Next.js 时期的博客，Nuxt Content 必然会是我的下一个选择 —— 这样复杂度必然会上去就是了（（。

总结

竟然不坏！竟然远超预期！

那么恭喜 Nuxt.js 成为我喜欢的仅次于或者说并列于 Next.js 的前端框架了！