精讀《前端將來展望》

1. 引言

前端展望的文章愈來愈很差寫了，隨着前端發展的深刻，須要擁有很是寬廣的視野與格局才能看清前端的將來。

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

• A Look at JavaScript’s Future
• 前端開發 20 年變遷史
• 前端開發編程語言的過去、如今和將來
• 繞過技術紛爭，哪些技術決定前端開發者的將來？
• 將來前端的機會在哪裏？

讀完這幾篇文章能夠發現，即使是最資深的前端從業者，每一個人看前端將來也有不一樣的側重點。這倒不是由於視野的侷限，而是如今前端領域太多了，專精其中某幾個領域就足夠了，適量比全面更好。

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

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

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

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

若是你想參與討論，請 點擊這裏，每週都有新的主題，週末或週一發佈。前端精讀 - 幫你篩選靠譜的內容。

關注 前端精讀微信公衆號

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