这是一个创建于 1099 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 。
Inspired by 《现代 Web 开发困境与破局》
 |
1
HarryYu 2021-11-05 07:01:11 +08:00
这条演进路线似乎有点偏技术了，我个人认为整个技术的演进主要还是业务驱动的。这是我的个人想法： 。
|
|
2
HarryYu 2021-11-05 07:01:47 +08:00
|
 |
3
weimo383 2021-11-05 07:21:38 +08:00 via Android
老哥，你推特上的 Internet screen shot 是啥项目啊
|
 |
4
oxogenesis 2021-11-05 08:20:04 +08:00
技术是为人服务，web 也不例外。
没抓住问题的核心，数据的归属权和控制权。 需要改变的是个人应该对自己的数据拥有完全的控制权。 https://github.com/oxogenesis/oxo-chat-app |
 |
5
cmdOptionKana 2021-11-05 08:39:39 +08:00
Server 的 IO 、CPU 、流量全是钱，学院派的想法当然希望采用最简洁、高效的模型，但现实要考虑成本啊。
|
 |
6
wanguorui123 2021-11-05 09:21:46 +08:00  1
Web 前端的核心价值在于对组件的封装和业务逻辑的分离，简单讲就是走桌面开发的老路
|
 |
7
NobodyMan 2021-11-05 09:39:56 +08:00
@wanguorui123 现在的什么单文件应用，构建打包，组件化，确实是桌面的那套东西
|
 |
8
xingyuc 2021-11-05 09:55:50 +08:00
各大云服务厂商的低代码、无代码平台做的不就是这事
|
 |
9
magichacker 2021-11-05 09:58:18 +08:00 1
前端：就问你摩登不摩登？
字节：你礼貌呢？ |
 |
10
nanxiaobei OP |
 |
11
vinle 2021-11-05 14:04:33 +08:00
我还好奇有人也对 Web 技术的未来感兴趣呢，原来只是 JS+CSS+HTML+PS+AI ，拜托拜托🙏建议标题改为“前端交互的过去与未来”，我就不会点进来，你的评论区也不会有我这种泼冷水的评论了。
|
|
12
nanxiaobei OP @vinle 哇塞你好贱，我喜欢
|
 |
13
abear 2021-11-05 15:34:10 +08:00
@nanxiaobei 抖
|
 |
14
caryyu 2021-11-05 16:19:15 +08:00
一场文明与粗鲁之间的较量，反复更替。
|
 |
15
star7th 2021-11-05 17:37:01 +08:00
未来随着对网页前端的复杂度提升，比如说交互友好，终端适配（说不定以后会出一个类似 vr 设备的硬件平台）等等，前端只会变得越来越复杂，复杂得就像一个本地客户端。而你却说未来把 data 得控制权给 server ，然后 ui 设计师直接驱动。这个是不太通的。因为前端 data 太负责了，后端 server 不会想要这个控制权的，大大增加维护负担。
|
 |
16
zjsxwc 2021-11-05 17:47:11 +08:00 via Android
|
|
17
nanxiaobei OP @star7th #15 其实最开始写的是「给后端」，又改成了「给 Server 」，主要是表达这个得解耦，由前端负责也合理。
|
|
18
nanxiaobei OP @zjsxwc #16 就像开车门槛也很低，给小学生开车，其实也能开
|
 |
19
israinbow 2021-11-05 21:50:00 +08:00 1
个人愚见: 设计与开发独立固然为好, 可局限很大, 主要跟业务方向有关.
设计师不懂开发的情况下, 做某种工具实现设计师画的图转换成带样式的 html, 其中的局限是只能产生平面设计. 倘若和图形学有关, 设计师能做到的就只有画原型图了, 这是科技与艺术的交锋, 鱼和熊掌的差异. 会画画的开发和会写代码的设计师都是最抢手的人才, 二者结合造出来的东西就是样式表和快速开发 UI. |
Select Language