上周面了个前端的小伙子，回答问题时用了Edge Rendering、Streaming SSR、React Server Components。我听完后就问了一句：那你知道这些听起来高大上的东西，和十年前用PHP写的有啥区别吗？
最近这两年前端开发的新名词是一浪接一浪的，Next.js、Nuxt.js、Remix等等等，它们个个都号称重新定义SSR。但抛开现象看本质你会发现，折腾来折腾去的，好像居然和PHP一模一样的，就是在服务器上生成HTML，让用户能快点看到内容，让搜索引擎能抓到东西。
当年的PHP
说出来可能很多开发者不信的，最早的服务端渲染其实就是PHP的本职工作。而且当年的PHP实现起来是很简单滴。
你只需要新建一个index.php文件，写几行这样的代码：
<html><head> <title>我的博客</title></head><body> <h1><?phpecho"今天吃什么"?></h1> <p><?phpecho get_article_content() ?></p></body></html>
然后用FTP拖到服务器上刷新浏览器就能看到结果了，没有npm install，没有几百MB的node_modules黑洞，没有webpack配置地狱，没有构建步骤，甚至没有版本冲突。服务器直接把数据拼到HTML里然后吐给浏览器，用户拿到就能看，点链接跳页面表单提交刷新，一切都顺理成章。
那时候我们根本不知道什么叫hydration，也不需要知道。因为浏览器拿到的就是完整的、可交互的页面，按钮点了就有反应，链接点了就跳转，没有任何的延迟。
SSR好像把简单的事搞复杂了
反观现在的SSR框架，好像有点复杂了。
就拿Next.js来说吧，你写个最简单的Hello World，得先初始化项目装依赖跑开发服务器。等你终于把页面跑起来了，新的问题又来了：
- 页面明明已经渲染出来了，按钮点了却没有反应，得等JS下载完了hydration跑完了才能实现交互
- 一不小心就会遇到
Hydration Mismatch报错，排查一下发现是服务端和客户端的时间戳不一至 - 数据获取要写两遍，服务端取一次，客户端还要再校验一次
我见过最离谱的项目，为了用SSR硬生生把一个原本用PHP半天就能写完的企业官网，搞成了需要三个前端一个运维维护的。最后首屏速度还不如PHP页面，是不是有点讽刺。
我们好像绕了一大圈
其实前端这十几年的发展，活脱脱就是一个从哪里来回哪里去的循环。
最早我们用PHP、JSP、ASP在服务端生成HTML，大家觉得交互太差。然后就搞了前后端分离，用React、Vue做单页应用，结果发现首屏太慢SEO太差，用户等不及，搜索引擎也抓不到，于是又开始搞SSR了。
绕了一大圈，我们又回到了服务端生成HTML的原点。好像只是为了和PHP区分开，还创造了一堆的新名词：
换了个马甲里子好像还是那个里子
不是否定SSR
我不是要否定现代前端技术，React、Vue的组件化开发体验，确实比当年PHP混写HTML强太多了。大型项目拆分成一个个独立的组件，维护起来方便多了。还有客户端的交互能力，比如无刷新跳转、实时更新、复杂表单处理，这些都是PHP时代没法比的。
对于需要大量客户端交互的应用，比如电商后台、社交APP、在线协作工具，Next.js、Nuxt.js这些框架确实是更好的选择。
但问题是，现在很多人不管什么项目上来就套SSR框架。明明只是一个简单的官网、博客或者企业展示站，用PHP写半天就能搞定，非要用Next.js，最后不仅搞得维护成本上升，性能也还没上去。
技术应该为业务服务而不是反过来
我做开发十几年最大的感悟就是：技术没有高低之分，只有适合不适合。
如果你的项目只是展示内容不需要复杂的交互，那PHP还是最好的选择。它简单、稳定、部署方便，一个人就能搞定开发和维护。如果你的项目需要大量的客户端交互，追求极致的用户体验，那现代SSR框架确实更合适。
就一句话技术是用来解决问题的。
