从「后端现在已经看不懂前端了」说起

原载于我的独立博客： https://lutaonan.com/blog/to-frontend-prejudicers

V2EX 这两天有一篇这样的帖子：《说句实话，我后端现在已经看不懂前端了，太难了》

原文内容是：

看不懂惹，肿么办，最近在学 react，完全抓瞎。

然后又附加了内容：

一直用的 jquery，手动找位置然后对应 dom 操作，现在各种前端各种依赖，一会 route 一会 webpack 的给爷整蒙了都。

类似这样的帖子多年来数不胜数，但这次评论区的评论比较典型，所以我决定这次不再沉默。当然，本文并非针对帖子作者。

对于那些抱怨前端「看不懂」的网友，我们应该问他们一个问题：为什么前端就应该是谁都能看懂？

这些网友从来不会抱怨别的领域的代码看不懂，比如他们不会说「我一个前端已经看不懂后端了」，或者「我一个后端已经看不懂 iOS 」了。

所以在这些网友心中，前端代码就是要谁都看得懂才是正常的。因为谁都应该看得懂 HTML, 谁都看得懂 CSS.

显然，这群人对前端的认知还活在过去，他们一边享受着用 Web 技术做出来应用，一边意淫着这些包含复杂业务逻辑的 Web 应用靠 HTML 和 Vanilla JS (原生 JS) 就能写成。

换句话说，这群人最大的问题在于，他们意识不到 GUI 开发 (Graphic User Interface Programming) 是一个从图形界面被发明开始就一直在被研究的独立领域，而 Web 前端只是 GUI 开发的其中一个分支而已。

这群人没有意识到到底什么是「前端」。前端就是写 HTML / JavaScript / CSS 吗？不，前端应该泛指那些需要编写 GUI 的技术。在我看来，写 iOS / Android 应用和写 Web 前端没有本质上的区别，区别只是语言和平台，背后处理的问题是一模一样的：如何实现视觉和交互 -> 交互如何触发逻辑 -> 逻辑如何影响视觉的变化。

所以，如果认为浏览器识别的是 HTML 所以认为前端应该谁都能看懂、门槛低，进而得出前端目前的工作流是问题复杂化的结果，就如同因为 Android 的 UI 是用 XML 写的就认为 Android 门槛低一样不成立得可笑。

对 GUI 开发难点的不了解是导致这种误解的最主要原因，以网友「 avastms 」提出的评论为典型：

这是前端圈长期逆淘汰的结果。

模板混代码里这种 PHP 宗教行为就别提了。

个人认为因为 javascript 语言的部分原因，前端很少有人懂什么是继承，什么是类，实例到底啥意思，更别谈良好维护引用了。

什么 redux,什么 vuex 根本就是莫名其妙，不就是事件监听吗，像 Node.js 那样 EventEmitter 多么清晰，非得自己造概念。

画虎不成反类犬，凡是有这套什么状态管理逻辑的，代码完全不可读。

前端自己也是不争气，不用别人的这些狗概念，自己就不会写代码了吗？

没有什么 redux，自己就不会管理自己的属性了吗？

他说：「模板混代码里这种 PHP 宗教行为就别提了」，想必他在说 JSX. JSX 刚开始出来就充满争议，但人们最终会发现，JSX 是函数式 GUI 开发最易读写的方案。实际上，他完全可以选择不使用 JSX，这样去写代码：

const Component = h(‘div’, null, [h(‘p’, null, ‘hello world’), h(‘p’, null, ‘I am Randy’)])

但是，这位网友大概更愿意读这样的代码：

const Component = (
	<div>
		<p>hello world</p>
		<p>I am Randy</p>
	</div>
)

觉得这样的写法恶心，多数是因为不知道 JSX 这个语法糖的背后是什么。

事实上没有人阻止任何人不用 JSX, 或者看看 Flutter 就大概知道没有 JSX 的 React 会是什么样子。

作为补充，这是希望 Flutter 引入 JSX 的相关讨论：Consider JSX-like as React Native · Issue #15922 · flutter/flutter · GitHub

至于提到的 Redux 和 Vuex, 证明这位网友根本不知道 EventEmitter 和 Reactive 的区别。这里就不展开讨论了。

为什么我们宁愿用 JSX 这种折中方案也不愿意放弃函数式编程，是因为声明式(Declarative) 是编写 GUI 最好的方法。复杂的 GUI 应用包含复杂的状态，人脑在处理复杂的状态绝对不比计算机在行，我们尽可能地把这些状态交给计算机做，函数式编程就是我们实现这个目标的工具。

Elm 的作者写过一篇名叫 Concurrent FRP 的论文，讲述了函数式响应式编程 (Functional Reactive Programming) 在 GUI 开发中的历史背景和应用。

那些喜欢说「 jQuery 一把梭」的网友，要么遇到的业务很简单，要么是在自虐。我见过写外挂用易语言一把梭的，但没听说过 Adobe 写 PhotoShop 用 Visual Basic 一把梭。

有些人，能接受 Maven, Gradle 的不完美，也知道什么场景应该用什么技术栈，但一旦开始写点前端代码，就认为应该有一个神一样的、完美的、还没有学习成本的构建工具，然后 Twitter, V2EX 抱怨一番，却不愿意认真学一学前端这个领域的知识。

不要妄想有一个睡醒就突然会用的构建工具。说实话，Webpack 不需要任何配置就能用，再不行试试号称 zero configuration (零配置) 的 Parcel, 用 TypeScript, 引入 CSS / LESS / SASS 通通不需要配置，跑起来就行。但那又如何呢，那些不愿意学习又想出活的网友们不懂的不是运行 webpack dev 这个命令，而是根本不懂这个命令背后解决的是什么问题。

一个人要锤子锤个钉子，结果大家都说雷神的锤子很牛逼。这个人听了，上来就要用雷神的锤子，结果拿都拿不起来。然后网上发个贴：「根本不懂为什么雷神要搞个这么重的锤子，给爷整蒙了都」。底下评论：「我工具锤一把梭！」楼下再附和：「雷神搞这个锤就是为了装逼」。

奉劝各位，把抱怨转化成求知，没有一个领域是不需要学习成本的，不管是做技术还是技术以外的领域，是分工和市场经济让各位觉得一切理所当然，然而像磨刀这样看上去简单的动作，也不是每个人都能磨好一把刀。

chinuno

2020-01-08 08:22:38 +08:00

等下。难道前端追求的是到最后谁也看不懂，或者只有 1%的人能看懂吗？
前端本来就是计算机程序设计的一部分，以前也没分什么前端后端都是一个程序员去搞定的，后面为了节约成本任务细分才出来的前端吧。
你考虑一下这种情况：就不加前端这部分了，单纯说后端。一个后端程序员，过去一年都在写基础库，没有接触到什么 web 框架没有写后端程序对外提供接口。现在工作变动需要重新写后端服务了。为了方便叫他 a 吧。
刚开始写，发现过去一年内出现了好几个 web 框架，而且全世界都在用。网上找找后端服务的源码想参考一下，都是用的这些框架写的。
a 想了想，不就是重新学个框架吗，分分钟上手。他挑选了个看起来好多大项目都在用的 axx 框架准备上手，然后发现文档特别复杂。编译就需要另外装个编译系统，配置上百个参数。打包发布也需要编译系统上再配上百个参数。
看到单纯配置环境就这么麻烦了，他想换个不需要这个编译系统的框架，结果发现全世界的框架配置起来都这么麻烦，最后决定还是用回 axx 框架。
a 找了几个 axx 框架的项目源码想参考一下，发现用 axx 框架还需要学一门新的语言叫做 t 语言。然后编译器再把 t 语言编译成 Java 代码，Java 再编译成字节码在虚拟机运行。a 还算是个求知欲比较强的人，并不抗拒学个新语言。但是项目排期只给了一个月，还要学个新语言项目肯定做不来了。
对比了其他的几个框架，a 另外找了同样许多大厂在用的 rxx 框架。rxx 倒是不需要学新语言了。但是 rxx 还需要写 jxp 文件。a 想了想，jxp 在代码里混合 Java 和 html 不就是以前的 jsp 吗？好不容易都前后端分离了结果现在又把他们搞在一起了？不过又不是不能用，想想剩下半个月的工期，a 还是用了 rxx 开始写程序了。
rxx 的编程思想确实有点与众不同，一套思维方式需要花点时间才能消化。对于聪明的 a 来说不是什么问题，3 天就完全摸懂 rxx 的编程思想了。
a 发现 rxx 虽然用起来不错，但是功能太少啦，许多明明可以集成到框架的基本功能 rxx 都不提供。于是 a 不得不自己进行扩展完善了许多基础功能。这个时候工期剩下一个星期。
a 想着这下终于可以真正开始写业务代码了。这时 rss 订阅列表出来了一篇新文章：“我是如何一星期把项目移植到 vxx 框架的”。a 有点好奇 vxx 又是什么？搜索了一下，发现又是一个新框架，上个星期才刚出来的。gayhub 上一看，最近一星期的新项目已经是 vxx 的天下了，最近一星期只有一个新的项目用了 rxx 框架。
a 看了看网上对 vxx 框架的评论，发现 vxx 并不像 rxx 一样基础功能都要自己实现。看了看自己刚加班那么多天写的 rxx 那些基础扩展，陷入了沉思。。有这么多时间直接用系统 api 写个简单的 socket 监听返回结果都没这么累