Next.js 有什么问题?
之前一直有想要抛弃 Next.js 的想法, 为什么呢? 你看看, 有那个 web 框架会像 Next.js 这样的, 三天两头的爆安全漏洞? 在前几天, Github 又往我的邮箱里塞 Next.js 的安全警告, 最后实在是忍无可忍了, 在最后一次更新了我的博客前端之后就直接把他归档了. (虽然说 "前端无安全", 但也指的不是这个 "无安全" 啊!)
虽然说 Next.js 是一个主打开发体验的 web 框架, 并且它的体验也确实在这片领域里一骑绝尘. 但是, 这只是针对常规且正常的开发流程而言的, 如果你想鼓捣一点奇奇怪怪的东西呢?
之前因为我需要在页面上动态的渲染 React 根组件, 所以在 Next.js 中使用了一些 React 的 API, 但是不知道是触发了 Next.js 的什么奇怪的 feature (我更偏向于是 bug), 我写的 hook 死活过不了编译. 最后没办法, 让 AI 来帮忙, AI 在鼓捣了两大圈之后能跑了, 但是为什么能跑? 我不知道啊? 他给的代码与我自己的也没有什么太大的区别, 但是他的就是能跑, 但是我的连编译都过不了. 并且, 离谱的是, 我稍微动了一下 AI 给的代码, 然后...也编译错误了?! 有时候写代码挺无助的.
Next.js 也是出了名的高 "心智负担", 各种隐含规则, 模糊的运行时边界 (use client, use server), 跟魔法一样的 server action, 还有神秘的水合错误. 写代码的时候时时刻刻都要注意各种规则, 不然的话可能一不小心就把某些东西写炸了. (怎么把 js 搞得跟 Rust 一样, 但是起码 Rust 的安全性也是真的啊.)
替代品
那么在 Next.js 之后如何选择一个新的前端呢? 首先我的需求有那些? 想了想大概可以分为以下几点:
- 高客户端性能, 毕竟当初选择 Next.js 而不是纯 React, 就是因为有 SSR, 性能表现更好.
- 无须服务端, 客户端直接请求我的后端, 之前因为想着在 Next.js 这边分一点逻辑可以让网站的整体响应速度更快一点, 但是写到后面导致开发体验极度割裂, 一个简单的操作要硬生生割成两段 (有时甚至更多).
- 多页站点, 因为我的博客功能相当简单, 现代化的 SPA (Single Page Application, 单页应用, 一个网页就是一个完整的应用程序) 框架明显有点多余了, 而多页能获得更好的 SEO 和首屏加载性能.
"我们花了十年时间把渲染从服务端搬到浏览器 (CSR), 现在又花十年时间把它搬回服务端 (SSR), 并称之为 '未来'."
我本来想的是 Astro.js, 这个著名的 "博客专用" 框架. 但是 Astro 的性能来源于 SSG (Static Site Generation, 生成一个不需要服务端的静态站点), 如果想让他保持实时性的话那就又需要一个服务端或者是变成单页应用. 直到我都已经开始上手写了, 才发现了这些问题. 也罢, Astro 看来貌似并不适合.
在鼓捣了一圈之后, 突然发现, Django 好像是自带 SSR 来着? 就是 Django 的模板引擎, 在我刚学 Django 就被我抛弃的东西. 因为他实在是太 "复古" 了. 在 6202 年还有人手动拼接字符串来渲染 HTML 页面吗? 并且他也是真的不需要单独维护一个服务端了, 直接跟原有的 Django 后端拼在一起就行.
没想到事情最后会以这样的方式解决, 兜兜转转了一圈, 结果发现自己又回到了原点, 真是件神奇的事. 难怪说 PHP 是世界上最好的编程语言.
虽然但是, 感觉一下子年轻了 20 岁, 对此你有什么头绪吗. (说起来, 现在的 Django 好像确实也是 20 岁)
新前端?
首先, 我的前端肯定不能是完全 HTML 拼接成的, 我打死都不要写原生 JS! 那么还有那些方案是可行的呢? 在 AI 的推荐下, 我找到了 HTMX.
HTMX 是一个很神奇的东西, 在前端都在追求 SPA 的时候, 他却反其道而行之, 把前端的逻辑全部都塞回后端.
具体是怎样的呢? 现代的 SPA 一般都是使用 JSON 格式的接口, 但是 HTMX, 就跟他的名字一样, 使用的是 HTML 格式的接口. 也就是说在 HTMX 向后端发起请求之后, 拿到的其实是后端发来的 HTML, 然后 HTMX 只需要原封不动的把这段 HTML 塞进页面上预设的一个位置.
没错, 它甚至还是 SSR! 本来还觉得这个框架还没什么的, 并且还觉得它的操作性太低了, 应付不来复杂场景, 但是想到这里突然就心动了.
那么后端与前端的交互的问题解决了, 那么如何解决前端与用户的交互呢? 要知道有些东西是不可能被搬到服务端去的, 比如说音乐播放器之类的在需要在客户端实时渲染的组件.
为此, 我还引入了 Solid.js, 这是一个相当轻量的前端框架, 使用 gzip 算法压缩之后只有 6kB. 相对的, React 则接近 50kB. 并且, 和 React 一样, 它使用的也是 JSX 语法, 对于之前学过 React 的人来说学习成本也比较低.
但是, 我也不是每个页面都需要 Solid.js, 因为页面大致的框架是由 HTMX 所搭建的, 我只需要使用 Solid.js 给他加入一些动态的组件就行了. 为此, 参考 Astro, 我也使用了类似于 Astro 的 "群岛架构". (其实就是动态的识别页面的占位符, 如果找到了, 就使用 SolidJS 把对应的组件塞进去. 没错, 说得这么高大上, 其实解决方式就是这么简单.)
那么前端的技术栈到这里大致就鼓捣的差不多了. 不对, 差点忘了, 还有 TailwindCSS, 因为我不会写 css, 所以一个 TailwindCSS 也是必须的. 要我说的话, css 就是世界上最难的编程语言. (如果它真的被归类为编程语言的话)
那么最后的, 如何编译这些产物, 让 Django 产出的 HTML 能够引用呢, 想到这里既有 css, 又有 ts, 还有 tsx, 那么自然的, 再装个万能的 Vite 吧. 虽然在 Django 里用 Vite 有点抽象, 但是真的是能跑的, 甚至还有 Vite 提供的自动页面热重载. Django 前端的开发体验一下子就上来了.
(写到这里突然发现, 这次的主题不是讲 "抛弃现代前端" 嘛, 这真抛了吗? 看起来好像抛了, 但好像又没有完全抛掉)
并且, 我还发现了这个新前端的一些特性, 比如说 "渐进增强" (这个好像最近都不怎么听得到了), 这是什么意思呢? 首先, 一个页面他应该首先只是一个简单的 HTML, 在条件允许的情况下再 "升级" 成应用程序. 没错, 他甚至允许你关掉浏览器的 JS 功能, 关闭 js 的话, 在大多数的现代网站的上都会导致页面故障, 甚至可能完全无法使用, 但是这个新的前端是可行的, 至少理论可行 (大概吧).
以及整个前端流程都是从最基础的 HTML 开始搭建的, 相当于整个渲染流程透明化, 所以他的 "魔法" 是相当少的, 不会像一些大型框架一样, 写到最后都分不清是 feature 还是 bug. 唯一美中不足的就是在处理老版本的浏览器的时候, 可能会有各种各样的兼容性问题就是了, 毕竟我只能保证在我的浏览器里他是一切正常的, 而现代化的框架是会自己帮你完成这些的
那么现在唯一剩下的问题就是如何处理这个 solid.js 的占位符了, 说到处理 TSX 文件的占位符, 第一反应肯定就是 SSR + "水合" 了. 但是我认为水合是个 "坏东西", 它会让原本就很简单的流程变得复杂化 (比如 Next.js 的水合错误, 写过的都懂), 而我写代码的倾向恰好又是 "为了代码的可维护性愿意牺牲部分性能" 的. 但是没有 SSR 生成占位符的话, 页面占位符的样式又需要花很大的力气去同步.
更新, 最后还是决定 SSR + 水合, 那么现在前端的的渲染管线就变成了完全分离的两条, 一条是编译运行在用户浏览器里的浏览器 js 脚本, 一条是编译用于服务端生成 SSR 的 node.js 脚本.
但是吧, 因为 Django 的性能, 只能说懂的都懂, 不能算得上是很强, 但是至少也是有在 web 框架性能排行榜上压轴登场的水平. 所以我并不打算在 Django 里再塞一个 node.js, 用编译时产出的占位 HTML 就已经够了.
(之前一直听别人说 Django 的扩展性强, 但是我一直都不知道强在哪, 现在一看, 确实很强, 甚至有点强的吓人了)
最后, 看看 AI 们对这个新的前端有什么看法
gpt-5.4:
