前端框架+ssr 比直接用后端的模板有什么优点么

[xcstream]

·

[dcalsky]

优点是可以用前端框架 你自己说了

[jimliang]

js/ts 一套带走

[richangfan]

增加了前端的话语权

[WittBulter]

区别很大，从性能到体验都不一样。
如今的 SSR 框架不仅是在做以前 Server Template 做的工作，更多的还承载了优化、切割、用户体验、开发者体验等多个方面。很多人并没有深度实践，只是想当然的认为这是前端搞事，没有什么实际价值。实际上 SSR 可以做的事情非常多：

1. SSR 可以在不改动代码的前提下自动最小化渲染首屏。传统的服务端模板渲染想要做到这一点的工作量非常非常大，要对 JavaScript 做切割，这不是简单的切割还要考虑工具函数、依赖包、样式代码块的体积分配，即便你粗暴的以最低 HTML 渲染出了首屏，也并不一定是可交互的、并不能完全避免 reflow 、保证共享资源的缓存等。

2. SSR 极大的提高了服务端直出的开发者体验。拿 Next.js 和传统的 JSP 距离来说，如果你的首屏资源涉及纯静态 (打包时插入的可配置文本资源)、纯动态 (第三方持久化存储数据资源)、按路由首屏不同的的静态动态混合资源这些问题时，JSP 不是不能完成，但代价太高，你需要在完成上诉第一条的同时解决这些所有问题，代码也非常难以维护，甚至需要多种脚本插入。但 Next.js 几乎不用改变代码、仅仅是加几个函数就可以轻松的解决这些难点。

3. SSR 不会脱离你的生态圈。SSR 框架一般依附于某一个前端框架或库的生态系统，不改变你的代码很大程度上不会降低你对生态系统的依赖，这在复杂的需求时可以极大的提高开发体验。

4. 更高的缓存利用率。服务端模板直出的项目意味着你每个 Base HTML 都是 0 缓存的，因为需要通信才能确定页面是否有动态内容。但大多数 SSR 框架都可以做到在无第三方资源插入时自动静态优化首页为高缓存页面。我不是说 JSP 之类的技术无法完成这件事，但就目前看来，似乎没有任何一个项目是针对此做过优化的，也没有任何与之相关的生态。

----

当然如果你的页面足够小，或者是完全不考虑性能和体验时这些技术是没有太大区别的，SSR 的优势在你不关注任何技术优势和体验时是无法直观感受的，如果只是做一件事实现了功能，那么都一样。但我敢保证，即便是优化的非常彻底的服务端直出，在正确科学的迁移到 SSR 之后仍旧能获得巨大的提升 (多方面的)。

[lneoi]

前后端代码混杂在一起不利于维护，也不利于分工，体量大了起来分工干活很重要