精讀《前端未來展望》

黃子毅發表於2019-07-16
前端

1. 引言

前端展望的文章越來越不好寫了，隨著前端發展的深入，需要擁有非常寬廣的視野與格局才能看清前端的未來。

筆者根據自身經驗，結合下面幾篇文章發表一些總結與感悟：

讀完這幾篇文章可以發現，即便是最資深的前端從業者，每個人看前端未來也有不同的側重點。這倒不是因為視野的侷限，而是現在前端領域太多了，專精其中某幾個領域就足夠了，適量比全面更好。

同時前端底層也在逐漸封閉，雖然目睹了前端幾十年變遷的開發者仍會對一些底層知識津津樂道，但通往底層的大門已經一扇扇逐漸關閉了，將更多的開發者擠到上層區域建設，所以僅學會近幾年的前端知識依然能找到不錯的工作。

然而上層建設是不封頂的，有人看到了山，有人看到了星球，不同業務環境，不同視野的人看到的東西都不同。

有意思是的國內和國外看到前端未來的視角也不同：國內看到的是追求更多的參與感、影響力，國外看到的是對新特性的持續跟進。

2. 精讀

前端可以從多個角度理解，比如規範、框架、語言、社群、場景以及整條研發鏈路。

看待前端未來的角度隨著視野不同也會有變化，比如 Serverless 是未來，務實的思考是：前端在 Serverless 研發鏈路中僅處於使用方，並不會因為用了 Serverless 而提升了技術含量。更高格局的思考是：怎麼推動 Serverless 的建設，不把自己侷限在前端。

所以當我們讀到不同的人對前端理解的時候，有人站在一線前端研發的角度，有人站在全棧的角度，也有人站在業務負責人的角度。其實國內前端發展也到了這個階段，老一輩的前端開拓者們已經進入不同的業務領域，承擔著更多不同的職能分工，甚至是整個大業務線的領導者，這說明兩點：

  1. 前輩已經用行動指出了前端突破天花板的各種方向。
  2. 同是前端未來展望，不同的文章側重的格局不同，兩個標題相同的文章內容可能大相徑庭。

筆者順著這些文章分析角度，發表一些自己的看法。

框架

在前端早期，也就是 1990 年瀏覽器誕生的時候，JS 沒有良好的設計，瀏覽器也沒有全面的實現，框架還沒出來，瀏覽器之間就打起來了。

這也給前端發展定了一個基調：憑實力說話。

後面誕生的 Prototype、jquery 都是為了解決時代問題而誕生的，所以有種時代造就前端框架的感覺。

但到了最近幾年，React、Angular、Vue 大有前端框架引領新時代的勢頭，前端要做的不再是填坑，而是模式創新。國內出現的小程式浪潮是個意料之外的現象，雖然群雄割據為開發者適配帶來了一定成本，但本質上是中國在前端底層領域爭取話語權的行為，而之所以各大公司不約而同的推出自己的小程式，則是商業、經濟發展到了這個階段的自然產物。

在原生開發領域，像 RN、Flutter 也是比較靠譜的移動端開發框架，RN 就長在 React 上，而 Flutter 的宣告式 UI 也借鑑了前端框架的思路。每個框架都想往其他框架的領域滲透，所以標準總是很相近，各自的特色並沒有宣傳的那麼明顯，這個階段只選用一種框架是明智的選擇，未來這些框架之間會有更多使用場景爭奪，但更多的是融合，推動新的開發方式提高生產力。

在資料驅動 UI 的方式上，具有代表性的是 React 的 Immutable 模式與 Vue 的 MVVM 觀察者模式，前者模式雖然新穎，但是符合 JS 語言自然執行機制，Vue 的 MVVM 模式也相當好，特別是 Vue3.0 的 API 巧妙的解決了 React Hooks 無法解決的難題。如果 Vue 繼續保持蓬勃的發展勢頭，未來前端 MVVM 模式甚至可能標準化，那麼 Vue 是作為標準化的事實規範，還是和 JQuery 一樣的命運，還需觀察。

語言

JS 語言本身有滿多缺陷的，但通過 babel 前端工程師可以提前享受到大部分新特性，這在很大程度上抵消了早期語言設計帶來的問題。

橫向對比來看，我們還可以把程式語言分為：前端語言、後端語言、能編譯到 JS 的語言。

之所以有 “能編譯到 JS 的語言” 這一類，是因為 JS Runtime 幾乎是前端跨平臺的通用標準，能編譯到 JS 就代表了可跨平臺，然而現在 “能編譯到 JS 的語言” 除了緊貼 JS 做型別增強的 TS 外，其他並沒有火起來，有工具鏈生態不匹配的原因，也有各大公司之間利益爭奪的原因。

後端語言越來越貼場景化，比如 Go 主打輕量級高併發方案，Python 以其易用性佔領了大部分大資料、人工智慧的運算場景。

與此對應的是前端語言的同質化，前端語言繫結在前端框架的趨勢越來越明顯，比如 IOS 平臺只能用 OC 和 Swift，安卓只能用 JAVA 和 Kotlin，Flutter 只支援 Dart，與其說這些語言更適合這些平臺特性，不如說背後是谷歌、蘋果、微軟等巨頭對平臺生態掌控權的爭奪。Web 與移動端要解決的問題是類似的：如何高效管理 UI 狀態，現在大部分都採用資料驅動的思路，通過 JSX 或 Template 的方式描述出 UI DSL（更多可參考 前端開發程式語言的過去、現在和未來 UI DSL 一節）、以及效能提升：渲染和計算分離（這裡又分為併發與排程兩種實現思路，目的和效果是類似的）。

所以程式語言的未來也沒什麼懸念，前端領域如果有的選就用 JS，沒得選只能依附所在平臺繫結的語言，而前端語言最近正在完成一輪升級大遷徙：JS -> TS，JAVA -> Kotlin，OC -> Swift，前端語言的特性、易用性正在逐步趨同。需要說明的是，如果僅瞭解這些語言的語法，對程式設計能力是毫無幫助的，瞭解平臺特性，解決業務問題，提供更好的互動體驗才是前端應該不斷追求的目標，隨著前端、Native 開發者之間的流動，前端領域語言層面差異會會來越小，大家越關注上層，越傾向抹平語言差異，甚至可能 All in JS，這不是因為 JS 有多大野心，而是因為在解決的問題趨同、業務優先的大背景下，大家都需要減少語言不通帶來的障礙，最好的辦法就是統一語言，從人類語言的演變就可以發現，要解決的問題趨同（人類交流）、與國家繫結的小眾語言一直都有生存空間、語法大同小異，但不同語言都有一定自己的特色（比如法語表意更精確）、跨語言學習成本高，所以當國際化協作頻繁時，一定會催生一套官方語言（英語），而使用基數大的語言可能會發展為通用國際語言（中文）。

將程式語言的割裂、統一比作人類語言來看，就能理解現狀，和未來發展趨勢了。

視覺化

前面也說過，前端的底層在逐漸封閉，而視覺化就是前端的上層。

所以筆者很少提到工程化，原因就是未來前端開發者接觸工程化的機會越來越少，工程化機制也越來越完善，前端會逐漸迴歸到自己的本質 - 人機互動，而互動的重要媒介就是圖形，無論元件庫還是智慧化設計稿 To Code 都為了解放簡單、模式化的互動工作，專業前端將更多聚集到圖形化領域。

圖形和資料是分不開的，所以圖形化還要考慮效能問題與資料轉換。

視覺化是對效能要求最高的，因此像 web worker、GPU 加速都是常見處理手段，WASM 技術也會用到視覺化中。具體到某個圖表或大屏的效能優化，還會涉及資料抽樣演算法，分層渲染等，僅僅效能優化領域就有不少探索的空間。效能問題一般還伴隨著資料量大，所以資料序列化方案也要一併考慮。

視覺化圖形學是非常學術的領域，從圖形語法到互動語法，從一圖一做的簡單場景，到視覺化分析場景的靈活擴充能力，再到探索式分析的圖形語法完備性要求，視覺化庫想要一層層支援不同業務場景的需求，要有一個清晰的分層設計。

僅視覺化的圖形學領域，就足夠將所有時間投入了，未來做視覺化的前端會越來越專業，提供的工具庫介面也越來越有一套最佳實踐沉澱，對普通前端越來越友好。

BI 視覺化分析就是前端深造的一個方向，跟隨 BI 發展階段，對前端的要求也在不斷變化：工程化、元件化、搭建技術、渲染引擎、視覺化、探索式、智慧化，跟上產品對技術能力的要求，其實是相當有挑戰性的。

編輯器

編輯器方向主要有 IDE（Web IDE）、富文字編輯器。

IDE 方向 國產做的比較好的是 HBuilder，國際上做的比較好的是 VSCode，由於微軟還同時推出了 Web 版 MonacoEditor，讓 Web IDE 開發的門檻大大降低。

作為使用者，現在和未來的主流可能都是微軟系，畢竟微軟在作業系統、IDE 方面人才儲備和經驗積累很多。但隨著雲服務的變遷，引導著開發方式升級，IDE 遊戲規則可能迎來重大改變 - 雲化。雲化使得作為開發者擁有更多競爭的機會，因為雲上 IDE 市場現在還是藍海，現在很多創業公司和大公司內部都在走這個方向，這標誌著中國計算機技術往更底層的技術發展，未來會有更多的話語權。

從發展階段來說，前端也發展到了 Web IDE 這個時代。對大公司來說，內部有許許多多割裂的工程化孤島，不僅消耗大量優秀的前端同學去維護，也造成內部物料體系、工程體系難以打通，阻礙了內部技術流通，而云 IDE 天生的中心化環境管理可以解決這個問題，同時還能帶來抹平計算機環境差異、統一編譯環境、原始碼不落盤、甚至實現自動的多人協作也成為了可能，而云 IDE 因為在雲上，也不止於 IDE，還可以很方便的整合流程，將研發全鏈路打通，因此在阿里內部也成為了今年四大方向之一。

所以今年可以明顯看到的是，前端又在逐步替代低水平重複的 UI 設計，從設計稿生成程式碼，到研發鏈路上雲，這種頂層設計正在進一步收窄前端底層建設，所以未來會有更多專業前端湧入視覺化領域。

富文字編輯器方向 是一個重要且小眾的領域，老牌做的較好的是 UEditor 系列，現在論體驗和周邊功能完善度，做得最好的是語雀編輯器。開源也有很多優秀的實現，比如 Quill、DraftJS、Slate 等等，但現在富文字編輯器核心能力是功能完備性（是否支援視訊、腦圖、嵌入）、效能、服務化功能打通了多少（是否支援線上解析 pdf、ppt 等檔案）、互動自然程度（拷貝內容的智慧識別）等等。如果將眼光放到全球，那國外有大量優秀富文字編輯器案例，比如 Google Docs、Word Online、iCloud Pages 等等。

最好用的富文字編輯器往往不開源，因為投入的技術研發成本是巨大的，本身這項技術就是一個產品，賣點就是原始碼。

富文字編輯器功能強度可以分為三個級別：L0～L2：

  • L0：利用瀏覽器自帶的輸入框，主要指 contenteditable 實現。
  • L1：在 L0 的基礎上通過 DOM API 自主實現增刪改的功能，自定義能力非常強。
  • L2：從輸入框、游標開始自主研發，完全不依賴瀏覽器特性，如果研發團隊能力強，可以實現任何功能，典型產品比如 Google Docs。

無論國內外都鮮有進入 L2 強度的產品，除了超級大公司或者主打編輯器的創業公司。

所以編輯器方向中，無論 IDE 方向，還是富文字編輯器方向，都值得深入探索，其中 IDE 方向更偏工程化一些，考驗體系化思維，編輯器方向更偏經驗與技術，考驗基本功和架構設計能力。

智慧化

筆者認為智慧化離前端這個工種是比較遠的，智慧化最終服務前後端，給前後端開發效率帶來一個質的提升，而在此之前，作為前端從業者無非有兩種選擇：加入智慧化開拓者隊伍，或者準備好放棄可能被智慧化替代的工作內容，積極投身於智慧化解放開發者雙手後，更具有挑戰性的工作。這種挑戰性的工作恰好包括了上面分析過的四個點：語言、框架、視覺化、編輯器。

類比商業智慧化，商業智慧化包括網路協同和資料智慧，也就是大量的網路協同產生海量資料，通過資料智慧演算法促進更好的演算法模型、更高效的網路協同，形成一個反饋閉環。前端智慧化也是類似，不管是自動切圖、生成圖片、頁面，或者自動生成程式碼，都需要演算法和前端工程師之間形成協同關係，並完成一個高效的反饋閉環，演算法將是前端工程師手中的開發利器，且越規模化的使用功效越大。

另一種智慧化方向是探索 BI 與視覺化結合的智慧化，通過功能完備的底層圖表庫，與後端通用 Cube 計算模型，形成一種探索式分析型 BI 產品，Tableau 就是典型的案例，在這個智慧化場景中，需要對資料、產品、視覺化全面理解的綜合性人才，是前端職業生涯另一個突破點。

3. 總結

本文列舉的五點顯然不能代表前端的全貌，還遺漏了太多方面，比如工程化、元件化、Serverless 等，但 語言、框架、視覺化、編輯器、智慧化 這五個點是筆者認為前端，特別是國內前端值得持續發力，可以做深的點，成為任何一個領域的專家都足以突破前端工程師成長的天花板。

最後，前端是最貼近業務的技術之一，業務的未來決定了前端的未來，創造的業務價值決定了前端的價值，從現在開始鍛鍊自己的商業化思考能力與產品意識，看得懂業務，才能看到未來。

討論地址是：精讀《前端未來展望》 · Issue #178 · dt-fe/weekly

如果你想參與討論，請 點選這裡，每週都有新的主題，週末或週一釋出。前端精讀 - 幫你篩選靠譜的內容。

關注 前端精讀微信公眾號

<img width=200 src="https://img.alicdn.com/tfs/TB...;>

版權宣告：自由轉載-非商用-非衍生-保持署名（創意共享 3.0 許可證）

相關文章