摘要：精讀前端可以從多個角度理解，比如規范框架語言社區場景以及整條研發鏈路。同是前端未來展望，不同的文章側重的格局不同，兩個標題相同的文章內容可能大相徑庭。作為使用者，現在和未來的主流可能都是微軟系，畢竟微軟在操作系統方面人才儲備和經驗積累很多。

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

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

A Look at JavaScript’s Future

前端開發 20 年變遷史

前端開發編程語言的過去、現在和未來

繞過技術紛爭，哪些技術決定前端開發者的未來？

未來前端的機會在哪里？

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

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

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

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

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

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

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

前輩已經用行動指出了前端突破天花板的各種方向。

同是前端未來展望，不同的文章側重的格局不同，兩個標題相同的文章內容可能大相徑庭。

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

在前端早期，也就是 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 就是典型的案例，在這個智能化場景中，需要對數據、產品、可視化全面理解的綜合性人才，是前端職業生涯另一個突破點。

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

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

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

如果你想參與討論，請 點擊這里，每周都有新的主題，周末或周一發布。前端精讀 - 幫你篩選靠譜的內容。

關注 前端精讀微信公眾號