博客新家:基于 next.js
自从 2017 年初把博客从 WordPress 迁移到 GitHub Pages 已经有 6 年的光景,在这些年里,Web 相关的技术发展日新月异,后端生成 HTML 的模式基本已经被抛弃,PHP、JSP 已经被扫进垃圾堆,一些编程语言已经老去,另一些则异军突起,GitHub Page 背后的 Ruby 不再闪亮,而 Web 平台则依旧长青。
我的前端技术栈从纯 HTML、CSS 和 JavaScript 开始,经历过 Vue 2,后来在 ClojureScript 环境中使用 React.js 的 Wrapper - Reagent,Reagent 是一段传奇,它在 React.js 早期的日子里做到了性能比原生 React.js + JavaScript 还要好,对日后 React.js 采用函数式组件起到了重要的影响。
我编写和维护的 CyberMe 前端项目,基于 ClojureScript 和 React.js,通过 re-frame 进行全局订阅、发布模式的状态管理(类似于 Rx),代码大概有 1w 多行。随着 JS 代码的增多,客户端渲染生成的 JS 文件越来越大,且丧失 SEO 能力意味着 SPA 单页 Web 应用的解决方案并不能覆盖所有场景。我调研了 JavaScript 世界的一些进展,也尝试了 Vite.js 和 Next.js、Tailwind CSS 等全新解决方案,但说实话,这些技术初看非常经验,实际使用也非常舒服,但深入进去就发现,它们往往在解决一部分问题的时候又带来了另外的问题,最后甚至还要考虑退回到最开始的路径是否可行。
Next.js 就是其中之一,它带来了服务端渲染,相比较纯模板模式,充分利用了 NPM 生态,大幅提升了非 SPA 应用场景下网页的开发效率和使用体验。配合基于 Rust 实现的工具链,开发环境稳定并且快速,非常好使。我在搭建新的博客站点的时候,大部分碰到的是 JavaScript 语言表现力不足以灵活操纵数据所带来的,以及对 Next.js 内部运行机制不熟悉导致的碰壁(典型的就是把仅服务端函数在客户端调用 —— 往往表现为报找不到 fs 模块的错误)。
Next.js 提供的其他特性,比如图像延迟加载和优化,路由跳转管理,SSG 数据生成等体验下来都很不错,但也并不是不可缺少。问题在于,它缺乏和多种场景其他工具协作的正交性,而这些功能,基于模板也可以做:缓存、反向路由,并且更透明,更容易适配到各种应用场景。从整套博客迁移下来,我由开始的激动到兴奋,逐步冷静下来,Next.js 的应用领域窄,但在这个领域:需要 SEO 的需要模板生成场景的建站场合,它做的确实很不错,React.js 即便不用来管理大量状态,其生态和 JS、CSS 组件化切实的能够改善大型站点的开发流程,甚至其还包括一些附加服务:从 Github 仓库一键部署到 Vercel,切切实实提升了个人开发者和小团队的效率。
Tailwind CSS 也是如此,它解决了很多问题,但并不完美,其需要配合 IDEA 或者 VSCode 插件的补全使用,加上略微翻一下文档,才能很轻松的修改样式,Tailwind 的原子化 CSS 并不是对 CSS 模块化的背叛,其只是打破了传统意义上的 CSS 模块 —— 通过约定双下划线和双横线的 CSS 模式库,但却很能够适应 CSS Module 或 CSS In JSX 等 JS 模块化方案,从这一点来说,它是成功的。只需要费很少的力气就能打造出还算不错的界面。
总的来说,Next.js + React.js 类似于 SwiftUI,在特定领域表现非常棒,虽然存在着不透明的黑盒,但使用起来很舒服。尽管如此,我大部分时间还是会写 ClojureScript + Reagent(React.js) 的 SPA,甚至在一些情况下直接将 Flutter APP 通过 WASM 部署到 Web,尽管 Clojure 和 Dart 看起来像是两种极端,但这种选择考虑的更多的是适用性,Flutter 远不如 SwiftUI 好用,代码冗余难读,运行效率一般,但 Flutter 程序可以轻松接驳 Rust,嵌套在 Android 和 iOS 设备中,和 Kotlin 与 Swift 基本无缝交互,这种适用性还是非常让人称赞的。至于 Clojure,它还是我通往 JVM 和 JS 平台和生态的入口,足够简单,普适,从日常脚本(SCI)到 Web 平台,再到长期运行的 JVM,它的普适性都很好。
可以说,对于 Flutter 的投资允许我在任何设备基本高效的提供 GUI 界面,对于 Clojure 的投资允许我享受到 JVM 变革(新的 FFI 和协程,以及亚毫秒级别的垃圾回收停顿,JDK 20)和 Web 变革(NPM 生态)的优势,Rust 也是如此。
即便未来出现了新的平台和语言,随手写一个 Clojure 解释器来访问这些新秀并不是困难的事情,考虑到 Clojure 现在已经有稳定的在 Clojure, ClojureCLR, ClojureScript, ClojureDart 实现,扩充一个 ClojureRust 和 ClojureSwift 也未尝不可 —— 总的来说,当使用了大量的编程语言,就会对软件充满戒备,包括那些闭源的,以及废弃的开源语言和工具,被抛弃是每个软件和编程语言生态不得不面临的问题,而充斥着 BUG 和缺陷的生态,总是会加速使用者的离开,最后,可能回想起年长者早年的劝诫:要有属于自己的代码。