折腾一圈后，我还是选择了 Nextjs

type

status

date

slug

summary

Honojs SSR

当初是 AI 给我带来的 Honojs，让我了解到这么一个可以在所有 javascript 运行时上运行的后端框架，同时这个框架使用体验也很棒，用起来感觉就像 golang 里的 gin，麻雀虽小，五脏俱全。

在想好要试试 SSR 以后，我第一反应还是使用 Honojs 来写，搭配 react19 引入的服务端组件，当时想的美啊，老子就是什么都要用最新的，哎，就是玩！

在网上一番查找，找到了一个别人搭建的模板，不过原模板是部署在 cloudflare worker 上的，但是我想试试常规的后端，于是就进行了一番改造：https://github.com/zaunist/Hono-React-SSR-Template

“水合”

接触到服务端渲染以后，第一次听说这个名词。它指的是服务端初始化渲染后的 html，被发送到浏览器端，浏览器端将客户端组件与这个 html 合并起来且再次渲染，而这个合并和再次渲染的过程就是“水合”。

一般来说，服务端会提供 html 模板，留下一些占位符，而客户端组件会被编译为静态文件，当在浏览器中再次组装时，编译产物能够补充上 html 模板中的占位符，这样就可以完整的显示网页效果。

我在前面所提到的项目模板实际上是可以工作的，确实也可以实现服务端渲染：https://github.com/zaunist/Hono-React-SSR-Template ，但是我还是选择放弃。

问题在哪里？

我基于这个模板做了一些简单功能的开发，然后开始遇到一些让我头疼不已的问题。

首先，Honojs 作为后端框架，后端接口的路由肯定是毫无问题的，但是当我使用它去实现服务端渲染，问题开始出现了，怎么实现客户端路由？

SPA 的路由很好理解，很轻松，全程都在客户端，鼎鼎大名的 react-router-dom 基本就能解决一切路由问题。但是在这个 SSR 项目里我搞不明白了，一个网站有多个页面，我在后端可以针对每一个页面都写一条路由，这样子网页是可以正常工作，但是每一次跳转都会是跳转→请求后端→渲染初始html→客户端水合。同时我也没有办法使用 react-router-dom，只能使用 window.location.herf 来跳转。

当我尝试在 honojs 中使用 react-router-dom 时，react 会报错，鉴于我对 react 的了解也不够深，问了 AI 好多次也没有找到真正的原因，也没有办法解决，那这个问题就得跳过去。

这个问题解决不了的话，那么每次跳转时都会刷新网页，有概率出现闪烁，又用不了 suspense 这样的组件（我一用就报错，没深究原理了），想一想，打开一个网站，动不动就闪几下，这体验简直不要太差，卒。

但是我希望达到的效果是将服务端路由和客户端路由相结合，比如页面A，B，C，D这四个页面，只有D使用服务端渲染，前三个仍然在客户端渲染，然后开发也需要有比较一致的体验，比如能共享部分组件库，能使用统一的处理逻辑，或者仅少量特殊处理逻辑，开发出来的效果也要比较好。

我做不到

我做不到，最大的原因是我对 react 的了解不够深入，同时我期望能够快速开发出一个项目，那么前面那种 react19+honojs 自己实现服务端渲染的方式就不得不被放弃。前端年年都在出新项目，东西多得学都学不完，我想做产品，而不是跑去研究 react 的底层原理，当然底层原理很重要，但是得排在快速产出后面。

我在使用 react19+honojs 的过程中，突然意识到所谓用了react19的“水合”，实际上跟模板引擎是有些类似的，我还去研究了 golang+react 的 SSR 项目，没想到还真的有，但是粗略一看我就知道这不是我要的效果，跟 honojs+react 相比，无非就是能够编译成一个更小的二进制，内存占用更低一点，相比于带来的开发心智成本，得不偿失好吧。

拥抱 Nextjs

我一早就知道 nextjs，但是我一直不是很想用它，我不喜欢大而全的框架，而且在 reddit 上看到过不少喷 Nextjs 的帖子，但现在不得不用了，相当多的人都使用 Nextjs 开发了项目，证明了它的可靠性，或许会有这那的问题，但是用的人多，解决方案就多，能被解决的问题那就不是问题！

计划

打算先用 nextjs 写个小项目练练手，熟悉用法以后，我在思考使用 nextjs 把 xugou 这个项目整个重构一遍，解决 xugou 的请求超时问题，以及多平台部署问题。