摘要：精讀前端可以從多個(gè)角度理解，比如規(guī)范框架語言社區(qū)場景以及整條研發(fā)鏈路。同是前端未來展望，不同的文章側(cè)重的格局不同，兩個(gè)標(biāo)題相同的文章內(nèi)容可能大相徑庭。作為使用者，現(xiàn)在和未來的主流可能都是微軟系，畢竟微軟在操作系統(tǒng)方面人才儲(chǔ)備和經(jīng)驗(yàn)積累很多。

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

筆者根據(jù)自身經(jīng)驗(yàn)，結(jié)合下面幾篇文章發(fā)表一些總結(jié)與感悟：

A Look at JavaScript’s Future

前端開發(fā) 20 年變遷史

前端開發(fā)編程語言的過去、現(xiàn)在和未來

繞過技術(shù)紛爭，哪些技術(shù)決定前端開發(fā)者的未來？

未來前端的機(jī)會(huì)在哪里？

讀完這幾篇文章可以發(fā)現(xiàn)，即便是最資深的前端從業(yè)者，每個(gè)人看前端未來也有不同的側(cè)重點(diǎn)。這倒不是因?yàn)橐曇暗木窒?，而是現(xiàn)在前端領(lǐng)域太多了，專精其中某幾個(gè)領(lǐng)域就足夠了，適量比全面更好。

同時(shí)前端底層也在逐漸封閉，雖然目睹了前端幾十年變遷的開發(fā)者仍會(huì)對(duì)一些底層知識(shí)津津樂道，但通往底層的大門已經(jīng)一扇扇逐漸關(guān)閉了，將更多的開發(fā)者擠到上層區(qū)域建設(shè)，所以僅學(xué)會(huì)近幾年的前端知識(shí)依然能找到不錯(cuò)的工作。

然而上層建設(shè)是不封頂?shù)?，有人看到了山，有人看到了星球，不同業(yè)務(wù)環(huán)境，不同視野的人看到的東西都不同。

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

前端可以從多個(gè)角度理解，比如規(guī)范、框架、語言、社區(qū)、場景以及整條研發(fā)鏈路。

看待前端未來的角度隨著視野不同也會(huì)有變化，比如 Serverless 是未來，務(wù)實(shí)的思考是：前端在 Serverless 研發(fā)鏈路中僅處于使用方，并不會(huì)因?yàn)橛昧?Serverless 而提升了技術(shù)含量。更高格局的思考是：怎么推動(dòng) Serverless 的建設(shè)，不把自己局限在前端。

所以當(dāng)我們讀到不同的人對(duì)前端理解的時(shí)候，有人站在一線前端研發(fā)的角度，有人站在全棧的角度，也有人站在業(yè)務(wù)負(fù)責(zé)人的角度。其實(shí)國內(nèi)前端發(fā)展也到了這個(gè)階段，老一輩的前端開拓者們已經(jīng)進(jìn)入不同的業(yè)務(wù)領(lǐng)域，承擔(dān)著更多不同的職能分工，甚至是整個(gè)大業(yè)務(wù)線的領(lǐng)導(dǎo)者，這說明兩點(diǎn)：

前輩已經(jīng)用行動(dòng)指出了前端突破天花板的各種方向。

同是前端未來展望，不同的文章側(cè)重的格局不同，兩個(gè)標(biāo)題相同的文章內(nèi)容可能大相徑庭。

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

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

這也給前端發(fā)展定了一個(gè)基調(diào)：憑實(shí)力說話。

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

但到了最近幾年，React、Angular、Vue 大有前端框架引領(lǐng)新時(shí)代的勢頭，前端要做的不再是填坑，而是模式創(chuàng)新。國內(nèi)出現(xiàn)的小程序浪潮是個(gè)意料之外的現(xiàn)象，雖然群雄割據(jù)為開發(fā)者適配帶來了一定成本，但本質(zhì)上是中國在前端底層領(lǐng)域爭取話語權(quán)的行為，而之所以各大公司不約而同的推出自己的小程序，則是商業(yè)、經(jīng)濟(jì)發(fā)展到了這個(gè)階段的自然產(chǎn)物。

在原生開發(fā)領(lǐng)域，像 RN、Flutter 也是比較靠譜的移動(dòng)端開發(fā)框架，RN 就長在 React 上，而 Flutter 的聲明式 UI 也借鑒了前端框架的思路。每個(gè)框架都想往其他框架的領(lǐng)域滲透，所以標(biāo)準(zhǔn)總是很相近，各自的特色并沒有宣傳的那么明顯，這個(gè)階段只選用一種框架是明智的選擇，未來這些框架之間會(huì)有更多使用場景爭奪，但更多的是融合，推動(dòng)新的開發(fā)方式提高生產(chǎn)力。

在數(shù)據(jù)驅(qū)動(dòng) UI 的方式上，具有代表性的是 React 的 Immutable 模式與 Vue 的 MVVM 觀察者模式，前者模式雖然新穎，但是符合 JS 語言自然運(yùn)行機(jī)制，Vue 的 MVVM 模式也相當(dāng)好，特別是 Vue3.0 的 API 巧妙的解決了 React Hooks 無法解決的難題。如果 Vue 繼續(xù)保持蓬勃的發(fā)展勢頭，未來前端 MVVM 模式甚至可能標(biāo)準(zhǔn)化，那么 Vue 是作為標(biāo)準(zhǔn)化的事實(shí)規(guī)范，還是和 JQuery 一樣的命運(yùn)，還需觀察。

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

橫向?qū)Ρ葋砜?，我們還可以把編程語言分為：前端語言、后端語言、能編譯到 JS 的語言。

之所以有 “能編譯到 JS 的語言” 這一類，是因?yàn)?JS Runtime 幾乎是前端跨平臺(tái)的通用標(biāo)準(zhǔn)，能編譯到 JS 就代表了可跨平臺(tái)，然而現(xiàn)在 “能編譯到 JS 的語言” 除了緊貼 JS 做類型增強(qiáng)的 TS 外，其他并沒有火起來，有工具鏈生態(tài)不匹配的原因，也有各大公司之間利益爭奪的原因。

后端語言越來越貼場景化，比如 Go 主打輕量級(jí)高并發(fā)方案，Python 以其易用性占領(lǐng)了大部分大數(shù)據(jù)、人工智能的運(yùn)算場景。

與此對(duì)應(yīng)的是前端語言的同質(zhì)化，前端語言綁定在前端框架的趨勢越來越明顯，比如 IOS 平臺(tái)只能用 OC 和 Swift，安卓只能用 JAVA 和 Kotlin，F(xiàn)lutter 只支持 Dart，與其說這些語言更適合這些平臺(tái)特性，不如說背后是谷歌、蘋果、微軟等巨頭對(duì)平臺(tái)生態(tài)掌控權(quán)的爭奪。Web 與移動(dòng)端要解決的問題是類似的：如何高效管理 UI 狀態(tài)，現(xiàn)在大部分都采用數(shù)據(jù)驅(qū)動(dòng)的思路，通過 JSX 或 Template 的方式描述出 UI DSL（更多可參考 前端開發(fā)編程語言的過去、現(xiàn)在和未來 UI DSL 一節(jié)）、以及性能提升：渲染和計(jì)算分離（這里又分為并發(fā)與調(diào)度兩種實(shí)現(xiàn)思路，目的和效果是類似的）。

所以編程語言的未來也沒什么懸念，前端領(lǐng)域如果有的選就用 JS，沒得選只能依附所在平臺(tái)綁定的語言，而前端語言最近正在完成一輪升級(jí)大遷徙：JS -> TS，JAVA -> Kotlin，OC -> Swift，前端語言的特性、易用性正在逐步趨同。需要說明的是，如果僅了解這些語言的語法，對(duì)編程能力是毫無幫助的，了解平臺(tái)特性，解決業(yè)務(wù)問題，提供更好的交互體驗(yàn)才是前端應(yīng)該不斷追求的目標(biāo)，隨著前端、Native 開發(fā)者之間的流動(dòng)，前端領(lǐng)域語言層面差異會(huì)會(huì)來越小，大家越關(guān)注上層，越傾向抹平語言差異，甚至可能 All in JS，這不是因?yàn)?JS 有多大野心，而是因?yàn)樵诮鉀Q的問題趨同、業(yè)務(wù)優(yōu)先的大背景下，大家都需要減少語言不通帶來的障礙，最好的辦法就是統(tǒng)一語言，從人類語言的演變就可以發(fā)現(xiàn)，要解決的問題趨同（人類交流）、與國家綁定的小眾語言一直都有生存空間、語法大同小異，但不同語言都有一定自己的特色（比如法語表意更精確）、跨語言學(xué)習(xí)成本高，所以當(dāng)國際化協(xié)作頻繁時(shí)，一定會(huì)催生一套官方語言（英語），而使用基數(shù)大的語言可能會(huì)發(fā)展為通用國際語言（中文）。

將編程語言的割裂、統(tǒng)一比作人類語言來看，就能理解現(xiàn)狀，和未來發(fā)展趨勢了。

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

所以筆者很少提到工程化，原因就是未來前端開發(fā)者接觸工程化的機(jī)會(huì)越來越少，工程化機(jī)制也越來越完善，前端會(huì)逐漸回歸到自己的本質(zhì) - 人機(jī)交互，而交互的重要媒介就是圖形，無論組件庫還是智能化設(shè)計(jì)稿 To Code 都為了解放簡單、模式化的交互工作，專業(yè)前端將更多聚集到圖形化領(lǐng)域。

圖形和數(shù)據(jù)是分不開的，所以圖形化還要考慮性能問題與數(shù)據(jù)轉(zhuǎn)換。

可視化是對(duì)性能要求最高的，因此像 web worker、GPU 加速都是常見處理手段，WASM 技術(shù)也會(huì)用到可視化中。具體到某個(gè)圖表或大屏的性能優(yōu)化，還會(huì)涉及數(shù)據(jù)抽樣算法，分層渲染等，僅僅性能優(yōu)化領(lǐng)域就有不少探索的空間。性能問題一般還伴隨著數(shù)據(jù)量大，所以數(shù)據(jù)序列化方案也要一并考慮。

可視化圖形學(xué)是非常學(xué)術(shù)的領(lǐng)域，從圖形語法到交互語法，從一圖一做的簡單場景，到可視化分析場景的靈活拓展能力，再到探索式分析的圖形語法完備性要求，可視化庫想要一層層支持不同業(yè)務(wù)場景的需求，要有一個(gè)清晰的分層設(shè)計(jì)。

僅可視化的圖形學(xué)領(lǐng)域，就足夠?qū)⑺袝r(shí)間投入了，未來做可視化的前端會(huì)越來越專業(yè)，提供的工具庫接口也越來越有一套最佳實(shí)踐沉淀，對(duì)普通前端越來越友好。

BI 可視化分析就是前端深造的一個(gè)方向，跟隨 BI 發(fā)展階段，對(duì)前端的要求也在不斷變化：工程化、組件化、搭建技術(shù)、渲染引擎、可視化、探索式、智能化，跟上產(chǎn)品對(duì)技術(shù)能力的要求，其實(shí)是相當(dāng)有挑戰(zhàn)性的。

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

IDE 方向 國產(chǎn)做的比較好的是 HBuilder，國際上做的比較好的是 VSCode，由于微軟還同時(shí)推出了 Web 版 MonacoEditor，讓 Web IDE 開發(fā)的門檻大大降低。

作為使用者，現(xiàn)在和未來的主流可能都是微軟系，畢竟微軟在操作系統(tǒng)、IDE 方面人才儲(chǔ)備和經(jīng)驗(yàn)積累很多。但隨著云服務(wù)的變遷，引導(dǎo)著開發(fā)方式升級(jí)，IDE 游戲規(guī)則可能迎來重大改變 - 云化。云化使得作為開發(fā)者擁有更多競爭的機(jī)會(huì)，因?yàn)樵粕?IDE 市場現(xiàn)在還是藍(lán)海，現(xiàn)在很多創(chuàng)業(yè)公司和大公司內(nèi)部都在走這個(gè)方向，這標(biāo)志著中國計(jì)算機(jī)技術(shù)往更底層的技術(shù)發(fā)展，未來會(huì)有更多的話語權(quán)。

從發(fā)展階段來說，前端也發(fā)展到了 Web IDE 這個(gè)時(shí)代。對(duì)大公司來說，內(nèi)部有許許多多割裂的工程化孤島，不僅消耗大量優(yōu)秀的前端同學(xué)去維護(hù)，也造成內(nèi)部物料體系、工程體系難以打通，阻礙了內(nèi)部技術(shù)流通，而云 IDE 天生的中心化環(huán)境管理可以解決這個(gè)問題，同時(shí)還能帶來抹平計(jì)算機(jī)環(huán)境差異、統(tǒng)一編譯環(huán)境、源碼不落盤、甚至實(shí)現(xiàn)自動(dòng)的多人協(xié)作也成為了可能，而云 IDE 因?yàn)樵谠粕?，也不止?IDE，還可以很方便的集成流程，將研發(fā)全鏈路打通，因此在阿里內(nèi)部也成為了今年四大方向之一。

所以今年可以明顯看到的是，前端又在逐步替代低水平重復(fù)的 UI 設(shè)計(jì)，從設(shè)計(jì)稿生成代碼，到研發(fā)鏈路上云，這種頂層設(shè)計(jì)正在進(jìn)一步收窄前端底層建設(shè)，所以未來會(huì)有更多專業(yè)前端涌入可視化領(lǐng)域。

富文本編輯器方向 是一個(gè)重要且小眾的領(lǐng)域，老牌做的較好的是 UEditor 系列，現(xiàn)在論體驗(yàn)和周邊功能完善度，做得最好的是語雀編輯器。開源也有很多優(yōu)秀的實(shí)現(xiàn)，比如 Quill、DraftJS、Slate 等等，但現(xiàn)在富文本編輯器核心能力是功能完備性（是否支持視頻、腦圖、嵌入）、性能、服務(wù)化功能打通了多少（是否支持在線解析 pdf、ppt 等文件）、交互自然程度（拷貝內(nèi)容的智能識(shí)別）等等。如果將眼光放到全球，那國外有大量優(yōu)秀富文本編輯器案例，比如 Google Docs、Word Online、iCloud Pages 等等。

最好用的富文本編輯器往往不開源，因?yàn)橥度氲募夹g(shù)研發(fā)成本是巨大的，本身這項(xiàng)技術(shù)就是一個(gè)產(chǎn)品，賣點(diǎn)就是源碼。

富文本編輯器功能強(qiáng)度可以分為三個(gè)級(jí)別：L0～L2：

L0：利用瀏覽器自帶的輸入框，主要指 contenteditable 實(shí)現(xiàn)。

L1：在 L0 的基礎(chǔ)上通過 DOM API 自主實(shí)現(xiàn)增刪改的功能，自定義能力非常強(qiáng)。

L2：從輸入框、光標(biāo)開始自主研發(fā)，完全不依賴瀏覽器特性，如果研發(fā)團(tuán)隊(duì)能力強(qiáng)，可以實(shí)現(xiàn)任何功能，典型產(chǎn)品比如 Google Docs。

無論國內(nèi)外都鮮有進(jìn)入 L2 強(qiáng)度的產(chǎn)品，除了超級(jí)大公司或者主打編輯器的創(chuàng)業(yè)公司。

所以編輯器方向中，無論 IDE 方向，還是富文本編輯器方向，都值得深入探索，其中 IDE 方向更偏工程化一些，考驗(yàn)體系化思維，編輯器方向更偏經(jīng)驗(yàn)與技術(shù)，考驗(yàn)基本功和架構(gòu)設(shè)計(jì)能力。

筆者認(rèn)為智能化離前端這個(gè)工種是比較遠(yuǎn)的，智能化最終服務(wù)前后端，給前后端開發(fā)效率帶來一個(gè)質(zhì)的提升，而在此之前，作為前端從業(yè)者無非有兩種選擇：加入智能化開拓者隊(duì)伍，或者準(zhǔn)備好放棄可能被智能化替代的工作內(nèi)容，積極投身于智能化解放開發(fā)者雙手后，更具有挑戰(zhàn)性的工作。這種挑戰(zhàn)性的工作恰好包括了上面分析過的四個(gè)點(diǎn)：語言、框架、可視化、編輯器。

類比商業(yè)智能化，商業(yè)智能化包括網(wǎng)絡(luò)協(xié)同和數(shù)據(jù)智能，也就是大量的網(wǎng)絡(luò)協(xié)同產(chǎn)生海量數(shù)據(jù)，通過數(shù)據(jù)智能算法促進(jìn)更好的算法模型、更高效的網(wǎng)絡(luò)協(xié)同，形成一個(gè)反饋閉環(huán)。前端智能化也是類似，不管是自動(dòng)切圖、生成圖片、頁面，或者自動(dòng)生成代碼，都需要算法和前端工程師之間形成協(xié)同關(guān)系，并完成一個(gè)高效的反饋閉環(huán)，算法將是前端工程師手中的開發(fā)利器，且越規(guī)模化的使用功效越大。

另一種智能化方向是探索 BI 與可視化結(jié)合的智能化，通過功能完備的底層圖表庫，與后端通用 Cube 計(jì)算模型，形成一種探索式分析型 BI 產(chǎn)品，Tableau 就是典型的案例，在這個(gè)智能化場景中，需要對(duì)數(shù)據(jù)、產(chǎn)品、可視化全面理解的綜合性人才，是前端職業(yè)生涯另一個(gè)突破點(diǎn)。

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

最后，前端是最貼近業(yè)務(wù)的技術(shù)之一，業(yè)務(wù)的未來決定了前端的未來，創(chuàng)造的業(yè)務(wù)價(jià)值決定了前端的價(jià)值，從現(xiàn)在開始鍛煉自己的商業(yè)化思考能力與產(chǎn)品意識(shí)，看得懂業(yè)務(wù)，才能看到未來。

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

如果你想?yún)⑴c討論，請(qǐng) 點(diǎn)擊這里，每周都有新的主題，周末或周一發(fā)布。前端精讀 - 幫你篩選靠譜的內(nèi)容。

關(guān)注 前端精讀微信公眾號(hào)