领导无脑 ssr、ssg

[rozbo]

最近领导沉迷上了 next.js 。我懂一个情节，就是刚学会某项技能，总是想把它用在方方面面，比如他这次想在中台上用 ssr ，理由是 next.js 生态很好，使用方便，基础设施，（尤其是 next auth ）能节省很多时间。

我的看法是，ssr 、ssg 这类技术对于现代网站(中古 seo)除外，简直是本末倒置，彷佛 csr 一文不值，而忽略了 csr 的许多优势

• 页面切换速度，（ csr 切换页面时，只需要向服务端请求一个短短的 api ，整体速度迅速且流畅，而且消耗的带宽很小）
• 而 ssr 、ssg 每次切换页面，都要重新拉取完整的页面，ssr 甚至都重新计算，速度和带宽占用都不如 csr 表现出色。
• ssr 、ssg 的 css 问题，如果使用了 css-in-js 这类的 ui 框架，那就更惨了，如果不进行 css 预提取，那将导致客户端闪屏(css 由 js 计算，而 js 异步加载，页面在 js 加载完毕后会闪动一下以应用新的 css 样式)，如果进行的 css 的提前烘培，则客户端会拉取双倍的 css(即拉取的预烘培的 css ，以及后续 js 里的 css)。

我实在不理解为什么还有人鼓吹 ssr 和 ssg 的性能，难道仅仅就是把 js 的一部分执行时间放在服务器上，性能就变好了？是服务端的性能好了，还是客户端的性能好了。。这中间导致的 FOUC 、css double 、page reload 以及带宽带来的损失，又该向谁说理去

[huijiewei]

你是不是对 SSR 有什么误解呀。。

[rozbo]

@huijiewei 确实了解不深，是我上面提出 ssr 的缺点有误吗？望批评指正

[huijiewei]

@rozbo 你首先要分清 SSR CSR SSG 和 SPA MPA 是不同的。SSR 优化的是首次加载。对于 SPA 来说，SSR 只有首次加载才有效，后面的切换和 CSR 没有什么不同，对于 MPA 来说会比较复杂一些，但是 MPA 你简单理解成 SPAxN 就好了。

对于任何 CSS-IN-JS 来说，都不可能没考虑到 CSS DOUBLE 的问题，如果有这个问题，说明这个 CSS-IN-JS 库很久没更新不支持 SSR 而已。不过有的 CSS-IN-JS 在 SSR 下面有性能问题倒是真的。所以我现在选择 TailwindCSS 。或者 ZeroRuntime 的。你们领导没让你们用 Qwik 搞恢复性就偷笑吧，SSR 已经是很保守的策略了。

[chloerei]

- next.js 的 ssr 按我理解是混合结构，每个页面可以在服务端渲染，然后在客户端绑定行为，之后的交互走客户端，切换页面和 csr 没什么差别。
- ssr 的公共内容可以缓存，节省了一些渲染和查询时间。
- ssr 可以优化首屏载入时间。
- 移动设备客户端性能并不总是令人满意。

我认为 Web 开发前后端分裂是很奇怪的事情，切割两端并不是最佳方案，未来还是会回到全栈。

[rozbo]

@huijiewei 感谢大佬
next.js 我用的 ssg 好像每个页面都生成了啊。。而且每次跳转都是全量的，我再研究研究怎么设置成 SPA 吧
另外确实，这些 ui 库都处理了 CSS DOUBLE ，比如 mui 中提到的策略，删掉之前服务端插入的 css ，然后替换成客户端生成，但无论怎么做，客户端实际上就是拉取了两份几乎差不多 css (css, css-in-js)，即使最终同时只应用了一份。我强迫症，真是觉得这方案不太完美，可能 tailwind 这种才是良配，不过组件什么的徒手撸确实太痛苦了。。。

[huijiewei]

@rozbo SSG 本来就是在构建时候就生成了 HTML ，然后引入 JS 给 HTML 注水产生互动。可能你做的 WEB 并不适用于 SSG 。SSG 适用于内容生产类。

[zmqking]

还以为是机场协议。。。

[Track13]

next.js 的 ssg 在切换页面的时候也是 csr 吧。
每个页面都生成了只是在刷新和首次加载的时候才用上。就是个预先生成的 ssr 。

[learningman]

“而 ssr 、ssg 每次切换页面，都要重新拉取完整的页面，ssr 甚至都重新计算，速度和带宽占用都不如 csr 表现出色”

先问是不是

[SolidZORO]

LZ 的所以疑虑都没错。

其他 SSR 框架行不行我不知道，但是 nextjs 的 SSG （这里权当 LZ 想要的那种开发后台的 SPA ）不要拿来和传统 CSR/SPA 比，完全没有可比性，就目前（ 2023-05-01 ） nextjs 仍旧没办法代替 CRA 开发 SPA ，因为 nextjs 没办法导出单一 index.html 的 SPA ，nextjs 前几个月被 Dan 狂 diss 了几回，说要搞一个 export SPA 的东西代替之前的 export ，但实际成品很难令人满意，我感觉就是换汤不换药。

结论就是拿 nextjs 开发 admin/dashboard 完全没必要，也非常不建议，本来 client 单方面能解决的事情，现在还得搭上个 render server ？？？ 时间多的话你随意。


另外，上了 SSR 肯定不会白屏，你用不用 cssinjs 都不会，但是 cssinjs 是肯定要在 runtime 花多一些时间处理 style 的，我个人觉得 cssinjs 是妖魔，从不待见。打算一路 css modules 走到黑。

[rozbo]

@SolidZORO 对，简直不能同意更多，这就是我想表达的，它完全没有一个 CRA 类似的能搞出来传统 SPA 的能力，之所以用 ssg 而不是 ssr 的原因很简单，就是不想再搭上一个 render server ，因为后端也不是基于 node 的，这样的话三端共存(前端、render server 、api server)，衍生了很多复杂问题(比如 api server 拿到的 user ip 其实是 render server 的，还要另外处理)，没办法才用了 export 模式。

这个模式就蛋疼了，生成了一堆 html ，然而这些 html 中，如果用了 css-in-js ，正常不管他它会再 pre render 时抽取 css 然后 inline 到 head 里，确实不会白屏，但是这样就导致 css 不会缓存，而且无限 inline 无限大，这个时候要考虑做抽取，但是抽取后就会导致帖子里说的一系列问题（ FOUC 、CSS DOUBLE ）等。

而为了解决这些问题，就需要使用 css module ，即基于完全基于 css 的 ui 库，准确的说是基于 tailwind css 的 ui 库，比如 flowbite ，不然就得徒手撸。总之，复杂了许多，但是估计着可能心理上会舒服一点。

但如果完全不想这些问题，无脑一把梭，估计也能凑合用，但是当越想到这里的细节，就越无法接受，隐隐觉得这简直是脱裤子放屁，直接 CSR 完全没有这里的烦恼。

真心希望 next.js 能有完全 CRA 的一天。

[Leviathann]

cra 是什么

[veike]

如果不是为了 SEO 我都不考虑 SSR ，
另外我不同意楼上说的“Web 开发前后端分裂是很奇怪的事情”，
我认为降低客户端代码和服务器端代码之间的耦合是非常有必要的，MVC 架构的 V 层从服务器端跑到客户端，我认为应该 MVC 应该去掉 V 层，不要再让它出现，除非你要考虑 SEO 。

[jsq2627]

要是用 nextjs 对标 CRA ，那还用 nextjs 干嘛，它优势不就是 SSR/SSG 嘛。。
而且管理后台类网站要 SSR 有何用，又不是给终端用户用，也不需要 SEO 。。而且有没有想过，你用的 table 组件也许根本不支持 SSR

SSR / SSG 唯一无可替代的优势就是 SEO 友好。

[makelove]

直接面向客户的东西，如果一定要追求极致用用还是个理由，毕竟首次加载快和 SEO 友好。
自己用的后台什么的有什么理由用呢？ csr 更简单, ssr 唯二的好处完全消失了。

[caqiko]

@Leviathann create react app

[estk]

他知道 next 的 app folder 吗？那个他知道了估计更想用。。

[Leviathann]

@caqiko 这玩意不是一个已经被废弃了的项目脚手架吗，和 nextjs 有啥关系

[neutrino]

@jsq2627 SEO 友好干嘛不用 MPA include 一堆呢

[Track13]

@estk 那楼主不得疯了，社区对 rsc 的接受度好像不搞，最近在用这个重构博客，之前用的那一堆里就 next-remote-mdx 支持了 rsc 。