领导无脑 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 。

[jsq2627]

@neutrino 这不关键还是想用 react 这种现代框架和生态嘛

[rocmax]

动态页面使用 ssg 是完全错误的，ssg 是用来生成静态内容的，做博客的话有 100 篇博客就生成 100 个页面。动态页面又不能确定内容的数量，怎么生成？推测 OP 的解决方法就是在客户端动态获取数据，于是又回到了 CSR 的老路上。。。
不过话说回来如果是写后台的话 csr 挺好，内部用的页面加载慢那么几毫秒有啥关系呢？
用 ssr 的话多一个服务是不可避免的，nextjs is a backend framework
https://dev.to/zenstack/nextjs-is-a-backend-framework-1mb9

[zhwithsweet]

我不怎么喜欢 nextjs. 原因如下:
1. swc 30m / turbo 12m / nextjs 本体 10m ；我是苹果电脑，硬盘和黄金一个价格；十分的珍贵；
2. 没有 SSR 的需求
3. 我更擅长用自己熟悉的技术栈解决问题；比如 vite rollup esbuild

重要：切换成 nextjs 全家桶，对我本人而言没什么收益；如果有明确收益，我会毫不犹豫的切换到任意技术栈

也不怎么喜欢 cssinjs. 原因如下:
1. 没有我用 unocss/tailwindcss 写的快；特别是在 适配屏幕、使用 icon 、编码速度上，使用原子类的优势是很大的；

对于楼主的问题：
1. 你可以给领导两个方案，nextjs 的排期和收益、vite or cra spa 方案的排期和对比；以及成本：nextjs 要一个 nodejs 服务器；后续成本：监控，巡检；服务器基本的 CPU/SYS/RAW 的监控，甚至需要有半个人力做前端运维；啊哈哈哈

2. 说服不了领导；要么忍、要么滚

[rocmax]

@zhwithsweet 第 2 条足够了，其他都是废话

[nbhaohao]

中后台管理系统项目确实不太适合 SSR, 应该是 CSR.

[otakustay]

中后台用 ssg 倒是没必要，数据本来就是动态的，能 ssg 出来什么东西。但 Next 的 ssr 要用还是能用的，和 csr 相比运维成本高些（毕竟多少得有个容器放在那），换来页面性能相对好一些，熟练了以后也不是不行

[BugCry]

听 OP 描述，并没有用 next.js 开发过完整项目吧
如果是有过相关经验，能够从项目角度比较为何 next 不如直接 cra ，也许还有一定的讨论价值，但只是从网上只言片语就得出这样的结论，那 V 友分析的越多，你也只会越迷茫
说到底，你也没办法推翻领导的决定，对吧(笑

[bojackhorseman]

我推荐你用 nuxt

[bojackhorseman]

@bojackhorseman 如果技术栈是 vue 的话

[Jackeriss]

这必须给你领导推荐一下 remix.js

[yrj]

我咋感觉 ssr 是提高性能的呢，反正我 spa 单页会卡。。。

[dayeye2006199]

无脑 SSG SSR 不可取。
但我觉得上 next 没啥太大问题。开箱即用，生态也不错。
没用到 SSG SSR ，部署也就是一静态网站

[mdn]

虽然无脑，但是选择方向正确

React 最新文档已经不推荐在无 framework 下使用，推荐基于 Next.js Remix 等框架 开箱即用，React 定位为 library
https://react.dev/learn/start-a-new-react-project#can-i-use-react-without-a-framework

并且 React 团队和 Next.js 团队之间有深度合作
https://react.dev/learn/start-a-new-react-project#bleeding-edge-react-frameworks

React 什么时候转给 Vercel 就好了🐶

[kingterrors]

你发的帖子表达自己的想法没哦有问题，但是重点是，你忽略了一点，那就是领导要用 ssr 的应用场景，你没有描述。所以无法判断领导的角色是一时头热还是经过慎重的评估。
结果这个帖子成了 ssr 和 csr 的引战贴。
至于哪种好，总的来说要看应用场景，楼上很多人说的很清楚了，这里不再复述。
我只补充一点，我印象中 next.js 首次是基于 ssr ，后面则是 csr ，同 nuxt.js ？这个是非常好的大型 web 应用解决方案。
另外，上面没有人提到同构应用。推荐阅读《同构 JavaScript 应用开发》也许你会发现，任何技术没有什么问题，问题在于使用方式。

[WIN2333]

@chloerei
@veike 这位老哥的意思是前后端分离应该指的是不应该出现前端和后端两个岗位吧，最近写了一个月前端，最大的感触就是联调的时候，有时候感觉讲半天不如我自己去把后台写了

[veike]

@WIN2333 前后端代码分类降低耦合肯定是好的，至于工作中前后端人员开发职责分离，我认为这种主要看公司安排，全栈的开发确实在某些环节要比前段后人员分开开发要节省时间一点。