领导无脑 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 以及带宽带来的损失，又该向谁说理去

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