1、最开始，网页只是用来看。Data → UI 是映射关系，所以最开始只有后端，因为后端把自己的 Data 转成 UI，这是最本能的开发模式。
2、Web 2.0 出现，网页变得可操作（从维基百科只能看，到 Blog 可评论），变成了 Data → UI → Action → Data，怎么处理 Action？这带来了 Ajax 崛起。
3、Ajax 崛起主要是因为体验好，以前的开发模式当然也行，效果就是发一条评论，网页就刷新一次，这显然是让人崩溃的（其实很多老的 WordPress 博客就是这么工作的）。
4、同时，浏览器性能提升，很多效果可以用 CSS 实现。网页就不只是 Data → UI → Data 这么简单了，同时还有 Loading、CSS 效果、动画、UI 切换等。
5、其实旧的开发模式，特别符合设计稿 → 网页的转化，什么按钮、圆角、阴影、特殊字体、动画，全都是一张图，设计师想改，换图片就行，不用改代码不用 build 不用发版。都使用 CSS 实现之后，才出现了设计到前端的转化问题（CSS 当然是有巨大优势的，比如天生的 responsive，这又表明了顺应时代，因为移动端带来了多屏幕尺寸问题）。
6、交互逻辑的大量涌现，与后端处理 Data 的开发思维是相悖的。为什么呢，想象一个完全没有 Data 请求的网页，也可以做的很炫酷很复杂，涉及大量 CSS、JS，这些工作谁来做呢？让后端来写显然不太合适。
7、这时，前端就出现了，简单来说，前端的出现就是为了处理交互。随着交互的工作量越来越大，而这又偏离了后端处理 Data 的思维，以至于不得不出现专门的工种来干这个。
8、所以处理 Data，其实只是前端工作中的一环，完全不是全部，如果只是处理 Data，后端来写 jQuery 处理不也行吗？
9、当然，现代组件库也隐藏了很多细节，比如 hover focus 态、button 点击动画、UI 切换、loading、自动布局、HTML 语义化等，都被包含在了组件库中。但即使如此，处理 Data 也只是一环，涉及到一些组件库无法覆盖的情况，还是需要前端来处理，更何况，组件库也是前端来开发的。
10、回到最本能的开发方式，最符合直觉的方式，其实是后端来处理 Data，前端来干其它的。但不太现实，因为 Data 与 UI 天生是绑定在一起的。
11、现代的前后端分离当然有一些问题，但同时也有不可替代的价值。其实往大了说，整个人类发展就依赖于分工。一个人不可能造出一部 iPhone，但分工协作可以。
12、即使完成数据源服务的全部设想，那么维护数据源的人，会成为新的后端，消费数据源的人，会成为新的前端。而数据源的变动，依然需要前后端协调。当然，数据「元」服务肯定是有价值的，但前后端协调还将存在。
13、本质上是因为，处理 Data、处理 UI 就是两种不同的思维，前者是理性的，后者是感性的。理性是能不能用，感性是好不好用，两者缺一不可。举个例子，DOS 不能用吗？但大家喜欢 Windows。直接刷新网页不能用吗？但大家喜欢 Ajax。人不都是一堆肉吗？但大家喜欢好看的。
14、各种变革到最后，很可能是解决一个问题，又带来了新问题，很可能是相比接口开发也没什么特别提升。而一个东西能不能产生革命性改变，决定了投入程度和未来的发展。
15、前后端协调肯定存在，这是个大前提，让设计师去写代码，这也很难。后端就是 Data，设计师就是 UI，前端就是 Data + UI 粘合剂，这是历史使命。
16、前端可以去研究怎么把 Data（逻辑） 与 UI 尽量分开，把逻辑更新与 UI 更新分开。因为按照 UI 改变量、就更新全局的思路，如果组件依赖于版本，不还是旧样式。所以，组件 UI 得来自外部，不依赖版本，就像组件 Data 是来自外部，不依赖版本。
17、参考一下旧时代的开发模式，设计师改图片源就行，与前端代码无关，此时 UI 来自于外部 URL。而未来 Web 开发，理论上组件 UI 也应该来自外部，自接口下发，跟组件自身代码解耦。
18、而组件的 Data 逻辑，也应该来自外部，尽量解耦。参考类似 FaaS 思维（Next.js 12 Edge Functions），直接在服务器上改函数就行，不用前端改个字段就得 build 一遍。
19、所以未来前端的工作，不是思考大一统，自己写后端，拉设计师写前端（当然，这也是一个思路，但很可能只是转化了工作，而各工种分歧依然存在）。而是思考怎么设计一套 Data 与 UI 充分解耦的架构，把 Data 控制权释放给 Server，让 Data 逻辑热更新，把 UI 控制权释放给设计师，让 UI 热更新。
20、前端呢，就负责维护这个外部变量「依赖注入」的充分解耦系统，没事别老 build。
Inpired by 《现代 Web 开发困境与破局》
