web渲染发展历程
远古时期的前端代码，都是夹杂在Php、Jsp、Asp的代码中，并且整个页面由服务器来查询数据并且填充拼接，最终生成的是一个完整的HTML页面，返回给浏览器可以直接去解析展现，到现在有很多网站还是这样的模式，比如下图这种：
随着时间的发展，这种模式的问题也逐步凸显。
从用户体验上来说，每次在页面上点击一个tab切换，都有可能是返回一个完整的Html，浏览器会重新刷新一次，这种体验是很难受的，因为有可能你在页面上勾选了一些状态会在刷新之后完全消失掉，这会让人感觉不是在使用一个应用，而是在不同的几个单独页面之间来回切换，使用体验非常不流畅。
从开发体验上来说，前后端的代码、仓库混在一起，前端工程师急需要独立的来做一些事情来提升开发体验和用户体验，此时Ajax技术出现了。
随着Ajax技术的广泛应用以及Vue、React、Angular等等技术的出现，前端单页应用越来越被前端工程师所接受。此时几乎所有的拉取数据、组装Html、渲染页面的工作都放到了前端来做，服务端的职责收敛到API请求来执行业务逻辑和获取数据，前后端的职责分明，分别把持网站的两头，中间是Http请求把他们串起来。
但是这种单页面应用的纯前端渲染也带来了一些问题，因为在首次请求的时候，服务器端只会返回一个几乎为空的Html（如下图），后续的内容数据都靠Ajax去动态的获取，如果要请求的数据很多的话，就会产生白屏，并且会有SEO问题。而且随着前端工程的膨胀，打包后的代码体积也会越来越大。
为了解决首次访问白屏问题以及SEO问题，大家把目光转向了SSR（服务端渲染），React社区推出了Next.js，Vue社区推出了Nuxt.js，它们都是在首次访问某页面时，直接在服务器端拼装一个完整的Html。
React Server Component
单页应用+部分页面SSR就是完美的方案吗？肯定不是的。做技术的都知道每种方案只是符合某些条件下的特定场景而已，随着业务复杂度上升以及技术债的堆积，SSR的问题也凸显出来，如果一个页面请求的接口很多，那么这个页面在服务端就会花费很长的时间才能拼装完成，那么响应时间依然过长。而且搞过SSR的同学都知道，这里面踩坑也不少。
到目前为止，我们已经清晰的知道前端开发的痛点了：
- 更好的用户体验：不能一言不合就白屏
- 更好的开发体验：组件尽可能的和业务解耦，不要写成一坨，更好维护
- 更好的性能：尽可能少的请求接口
对于权衡这3个痛点，React团队给出的解决办法是React Server Component，它可以让你：
- 在服务端运行React组件，并且这些组件永远不会被下载到浏览器中去，这样子就可以减小前端项目的打包体积
- 完整的服务端访问能力，比如直接在React组件中读取文件、访问数据库，在官方给出的demo中也看到了react-fs、react-pg这样的库
并且它和SSR的区别在于：
- SSR返回的是一个Html，而React Server Component返回的是一个React可解析的结构。
- SSR返回的页面会让页面重新刷新，丢失掉之前页面上的状态，比如表单选中之类的；而React Server Component返回的并不会让页面重新刷新而丢失状态。
使用场景
以React官方给的介绍视频为例，假如有这么一个常见的业务需求，1个父组件内套了2个子组件，并且每个子组件需要的数据不一样：
为了尽量的少发请求，我们一般会用1个接口去拿到2份儿数据：
但是这样子做的问题是，2个子组件与父组件耦合太严重，不利于维护，于是我们选择在2个子组件内各自请求数据：
但是这样子做相比上一种做法，多了2次接口请求，性能上会受影响，使用React Server Component重构来做就会是这样：
组件的业务数据拉取放在了服务端来做，并且服务端组件不会被打包到前端代码中，对于前端来说，整个网络请求只有一次。
我的看法
React团队提出的这项技术，社区也有过类似的，但这次不同的是它是基于React技术栈来做的，所以关注度和接受程度会比其他类似的技术更高一些。
从前端开发者角度来说，这项技术把Component的能力从前端扩展到了后端，以后说不定各大公司会出现前端组件公共服务之类的技术基建，可能会在以后改变现有的前端开发模式。
