我也讨厌 Tag，又不是 P 站，搞一堆 Tag 太多余了。我甚至不想要留言，看起来有点 low，像是很久以前的 BBS 一样信息信噪比不能看，国内还需要接内容审核，搞来搞去像个跳钢管舞的。对我来说，有内容，有较高的阅读体验就够了。

我把自己的博客开源之后，看数据大约有 15 - 20 人在使用，也有给我反馈的，其中大多数人都是比较喜欢简洁和优雅的。技术博客搞得花里胡哨，也显得人不成熟。

区别很大，从性能到体验都不一样。
如今的 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 之后仍旧能获得巨大的提升 (多方面的)。

@assclb MIT，随意用喔

@kakudesu 当然可以，你使用时可以自己调整这些色彩的😁

@Liulang007 说出来你可能不信，刚才在回滚，回滚的一瞬间 GitHub 挂了 (大约 10 - 20 分钟)，现在已经好了。

@DCCooper 行内代码的引号是设计元素🤔

@bnm965321 well, 这个可以给加上

@wenzichel 每隔一段时间就觉得自己以前写的东西都是腊鸡，看不下去，就全删了...🤣🤣

@Raven316 设计感这个见仁见智了😜没有办法

@im67 那个项目是很久以前留得一个坑，还没重构呢🤣🤣只是觉得这个名字有点谐~~

@hljjhb 唔 😢😢这个重要嘛..加上也不是难事，后续更新我注意一下这个功能吧

@1more
@dinjufen
嗯~🧐厚着脸皮发邮件问 GitHub 工作人员要的....

@geelaw 反式指针是设计的~~
移位这个看起来是一个 bug，但是我不能复现，能回复我具体说说浏览器之类的环境嘛，或者在 git 帮我开一个 issue ？

@lunatic5 嗯，这是故意设计的。看起来有些别扭，以后会一直优化设计的~

@missdeer 美滋滋

@secsilm 是的，google 的那个灯塔测试

也是前端，觉得很菜 +1
不会的东西太多了，有种无力感，有时候也会突然出现技术疲惫感。

感觉不错。
如果是开源的，有一些性能基线测试我想应该有不少人愿意用。