我不想成为不懂 GUI 的 UI 开发者

做为一个程序员，我是从切图开始职业生涯的。行业内通常把我这种编写用户界面 (UI) 的岗位，叫作前端开发。工做几年后我发现了个奇怪的现象，那就是整个前端圈子里，虽然你们经常谈 UI，但不多有人谈 GUI。

这话要从何提及呢？前端圈子里从上游到下游，强调的都是 UI 这个概念：

• 最上游的开源基础库，清一色地宣称本身是 UI Framework 或 UI Library。
• 业内同行交流时各类 PPT 里的架构图，经常在最上面画个名叫 UI 的模块。
• 与非技术同事们协做时，你们关心的主要也是 UI 设计稿和 UI 的开发排期。

但因为工做须要，我接触了一些浏览器以外的 UI 框架。有意思的是，这时候我常常能看到 GUI 这个概念了。好比 Qt 框架的核心模块名就是 QtGui，GTK 和 wxWidget 都将本身定义为 GUI 库，更不要说名字里带着 GUI 的 Dear ImGUI 了。那么问题来了，说本身作的是 GUI 仍是 UI，有很大的差异吗？

别小看 G 这个一字之差，这里的差异未必比 Java 和 JavaScript 的差异来得小。GUI 的 G 是什么的缩写？Graphics。少了这个 G 意味着什么？意味着今天的应用层 UI 开发，已经不太须要关心如何渲染 Graphics 图形了。

不少前端同窗可能会对此有意见，认为只要熟读了 Vue 或 React 等现代前端框架的源码，就已经对渲染这件事了如指掌了。若是你也这么认为，那么不妨问本身下面这么几个问题：

• 浏览器是如何将布局数据计算为像素数据的，你能实现出原理相似的渲染器吗？
• 浏览器在各个平台上的文字排版渲染结果是否一致，你能解释缘由吗？
• 你所负责的前端应用，其渲染性能还有多大的提高空间，你能量化地证实吗？
• 你能设计实现出相似 RN 和小程序那样的 Hybrid 方案吗？
• 你能本身控制 GPU 渲染管线，实现渲染的硬件加速吗？

它们不是孔乙己式的钻牛角尖面试题，而是对我所在的前端团队而言，很是具有探索乐趣和商业价值的实际问题。当开发普通的 Web 应用时，你大可没必要关心它们。但若是你但愿挑战 Web 的极限，在浏览器里跑起像 Office 和 PS 那样复杂的应用时 ，这些问题多半是绕不开的。在个人理解里，这些问题的答案，多数和如今浏览器里某种具体的 UI 框架关系不大，是更为「底层」的问题。

什么，难道 Web App 里还有比 React 和 Vue 源码更底层的东西吗？那就是 GUI 里的这个 Graphics，一我的类已经探索了四十多年的领域。

从 1979 年乔布斯造访施乐 PARC 算起，科技巨头们在 GUI 上的努力从未中止过。某种程度上说，前端开发的历史，不是从 jQuery 甚至 JavaScript 的诞生开始的，而是从 Macintosh 时代的上古平台开始的。当你用这种方式来回顾几十年来的 GUI 软件开发框架时，相信你会对软件工程架构的进步有全新的认识。

在我目前的理解里，GUI 应用的架构实现，依次走过了这些重要的阶段：

• 过程化绘制时代 - 直接调用 drawLine / drawRect 风格的 API 来绘制像素。在个人树莓派里，只要 include X11 的头文件，就能用 C 语言体验这种硬派的 GUI 开发了。HTML5 中的 Canvas，其实也属于这种风格。
• 面向对象抽象时代 - 纯粹过程化的代码，并不利于维护事件驱动的业务逻辑。好比，你须要自行计算来判断出某次点击应该选中哪一个 UI 元素。在 MFC 和 GTK 的时代，人们实现了面向对象风格的 UI 框架。按钮、输入框等 UI 控件具有了实例方法，能更好地组织代码。
• 界面与样式分离时代 - 用 C++ 系语言的代码来描述 UI，很容易写出面条式的丑陋代码。所以人们又引入了 XML 风格的语言，专门来表达嵌套式的界面。DirectUI 和 HTML / CSS / JS 基础上的经典 Web，都是这个时代的产物。
• MVC 与 MVVM 时代 - 如何维护日益复杂的 UI 交互逻辑？许多框架引入了软件工程中的 MVC 和 MVVM 等设计模式。这个时代的表明产物有苹果的 Cocoa 和微软的 WPF，以及 Web 上的 Angular 1 框架。
• 声明式组件化时代 - 为何咱们必须编写链接 UI 布局语言和业务逻辑的面条代码呢？Facebook 的 React 提出了新的 UI 开发思路。经过 JSX，很容易用 JS 来编写嵌套的、声明式的、更易维护的 UI 组件，并借助 JavaScript 的动态性来实时调试 UI。当前风口上的 Vue，Flutter 和 SwiftUI，都明显地借鉴了这种思想。

理解了 GUI 技术架构的演进后，就不难明白一些口水问题的答案了。例如在我一个关于拖控件式编程的知乎回答里，有些人反对个人论据是「拖控件比写代码更高效」。没错，拖控件属于界面与样式分离时代的产物，这确实比面向对象抽象时代编写面条代码更好。但到了声明式组件化时代，编写代码反而比拖控件更高效而方便了。

看起来一切都在进步，一切都欣欣向荣。长期被原生开发者们鄙视的 Web，甚至引领了最新的 UI 开发技术浪潮。但这有什么问题呢？

问题就是，Graphics 被封装得太好了，以致于都不须要被关心了。

在最先的 GUI 时代，计算机甚至是没有 GPU 的。你绘制的文字和图像，都是内存里的 Bitmap。这时的 UI 框架做者们，必须认真考虑如何优化窗口化的 2D 渲染，并实现文字渲染、布局算法、点击测试等基础功能。而到了装机必备独立显卡的时代，如何用 GPU 来实现硬件加速的渲染，也变成了一个新的重要课题。最后，现代 GUI 应用基本都须要一个异步非阻塞的 Main Loop 配合子线程来保证渲染不卡顿，这也须要对操做系统的多线程技术有充分的理解。

能够看到，要成为原生 GUI 库的做者，多半须要扎实的操做系统和计算机图形学基础。但在今天流行的 Web 和 App 平台，这些计算机基础知识，已经被藏在厂商提供的 API 后面了。而流行的 React 和 Vue 等 UI 框架，其输入和输出都已是至关结构化的数据，更不涉及困难的 Graphics 部分。虽然大多数场景下这些 API 是够用的，但当你须要更多的自由、更多的掌控时，你会发现本身被限制住了：你能用 JavaScript，直接读写某个 DOM 元素在某个像素下的颜色吗？

这种能力上的限制，不只影响了前端工程师的长期技术成长，还使得社区的风气都变得有些古怪。React 的声明式 UI 确实有用，但在其影响下函数式编程被社区奉为圭臬，某些布道者甚至连 for 循环都要抵制，这就有些舍本逐末了——要想掌握原生的图形渲染管线，几乎必须掌握很是命令式的编程。在渲染能力的限制下，整个社区的发展都倾向于关心代码自动格式化、强类型提示、编写更优雅的状态管理代码等层面的东西。这些技术方向当然有用，但多半只能增量地提升开发效率，并不能创造出全新的用户体验。

怎样突破标准化 API 的限制，创造出全新的用户体验呢？我很喜欢举 Photopea 的例子，这是个浏览器内的 PS 替代品（其国内版是咱们部署的 ps.gaoding.com）。当我在捷克与做者 Ivan 交流时，他告诉我通常的 Web App 可能有 90% 的代码是第三方框架实现的，但他的 Photopea 则有 90% 的代码都须要本身写。他将 PS 中各类重要的算法实现到了 Web 上，最终得到了 WOW 级别的图像编辑体验。他明确地告诉我，他并不认为本身是一个 Front End Developer，而是一个 Programmer，能根据须要去学习并解决具体的技术问题。他对技术的态度，对我我的有很大的影响。

固然，我相信 99.9% 以上的前端同窗，都不须要重复发明这么多轮子，更不须要在浏览器里实现一个 PS。可是如今国内的前端业界，对 GUI，对 Graphics，以致于对基础的计算机科学的理解，真的足够吗？不少抱怨 35 岁焦虑的同行根本没有认识到，前端框架快速变迁的真正缘由，在于 GUI 背后的整个产业链，还具有巨大的发展和改进空间，仍然处于朝气蓬勃而充满机遇的时期。当下一个机遇到来的时候，它必定只会给有准备的人。

回顾计算机产业的历史，几个对普通人影响最为深远的进步，都是和 UI 分不开的的：微处理器浪潮普及了命令行 CLI；我的 PC 浪潮普及了桌面 GUI；Internet 浪潮普及了 Web 网页；移动端浪潮普及了掌上 GUI。这些十年一遇的变革，深入地影响了咱们的平常生活。我相信在将来，Web 应用必定会更多地使用到浏览器以外的能力，和传统的 Native 技术栈有更多的链接和融合。须要对整个 GUI 系统及其背后的计算机科学有着更深入的了解，才能把握住这样的机会。

虽然我如今的 Title 是一个「前端工程师」，但我真正的理想，是成为一个自由的人。在职业生涯中，我追求的是发挥创造力的自由。当我入门时，浏览器给了我巨大的自由。但当我追求对渲染更高程度的掌控时，浏览器反而限制了个人自由。我确实很熟悉 JavaScript，但我也随时乐意拥抱不一样场景下更合适、更优秀的技术栈，以发挥技术自由而非语言偏见做为准则，向更多的 GUI 开发者们学习。

GUI 技术栈大团结万岁！

我主要是个前端开发者。若是你对 Web 结构化数据编辑、WebGL 渲染、Hybrid 应用开发，或者计算机爱好者的碎碎念感兴趣，欢迎关注个人公众号 color-album 噢 :)