我不想成爲不懂 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 噢 :)