前端開發(fā)的瓶頸到底在哪里，前端技術(shù)是否已經(jīng)走到一個(gè)十字路口，全?；南到y(tǒng)架構(gòu)是否能改變目前的窘境？本文將根據(jù)我自己的開發(fā)經(jīng)歷談?wù)劗?dāng)下前端開發(fā)中遇到的一些問題和想法。

引子

近兩年我一直在思考的一個(gè)問題：

如果前端不用考慮性能問題、不用考慮終端兼容性、不用考慮歷史遺留問題，甚至不用考慮具體技術(shù)實(shí)現(xiàn)…

如果我們假設(shè)自己有豐富的技術(shù)儲(chǔ)備，同時(shí)不用考慮上面的問題，那么前端究竟 能 做出什么樣有價(jià)值的東西？

我們把時(shí)間拉到 5 年前…

如果你「那時(shí)」還是前端開發(fā)的話。上面的問題肯定是你不得不面臨的典型問題。甚至是當(dāng)時(shí)前端開發(fā)的意義所在。

• 你會(huì)為了精確還原設(shè)計(jì)稿熬夜加班，從而練就一雙像素眼；
• 你會(huì)為了解決幾個(gè)字節(jié)的性能問題研究?jī)?yōu)化方案，以至看懂了每一個(gè) HTTP 請(qǐng)求頭；
• 你也會(huì)因?yàn)槟承┘夹g(shù)問題和同事理論，最終到達(dá)到產(chǎn)品談笑風(fēng)聲的境界；

但是隨著時(shí)間的推移，前端技術(shù)的更新迭代，以及互聯(lián)網(wǎng)的發(fā)展。你會(huì)發(fā)現(xiàn)這些曾經(jīng)的問題似乎已經(jīng)不再是問題，或者說在能預(yù)見的未來 可能 不再是問題。

頁面加載性能可能不再是問題，技術(shù)上有了 HTTP2，基建上有了 5G，硬盤也越來越快。

兼容性問題慢慢淡出大家的視角，Chrome 一家獨(dú)大，微軟也不得不向它靠攏。

很多前端開發(fā)已經(jīng)具備了后端（或者說多端）的技術(shù)能力，技術(shù)儲(chǔ)備也可能不是問題，當(dāng)然前提是你能招到人。

定義

到底什么是前端開發(fā)，前端與后端的界限在哪里？我在三年前對(duì)它的定義是：

前端為 界面、交互展示負(fù)責(zé)； 后端為 數(shù)據(jù)、業(yè)務(wù)邏輯負(fù)責(zé);

不過現(xiàn)在看來似乎已經(jīng)過時(shí)了，我越來越覺得不應(yīng)該有這樣一個(gè)清晰的界限把前后端分割開來，尤其是技術(shù)層面（除了職能層面的界限有利于協(xié)作以外）。這就好比說：如果你不能打破規(guī)則，那就必將被規(guī)則束縛。

我一直認(rèn)為程序員應(yīng)該對(duì)新的技術(shù)、工具、理念有比平常人更快的適應(yīng)能力。舉個(gè)簡(jiǎn)單的例子，我以前寫代碼通常使用 tab 縮進(jìn)，后來大家都建議使用空格，剛開始嘗試換成空格肯定是拒絕的，因?yàn)樽屓烁淖兞?xí)慣是一件很難的事情。但是當(dāng)你真正為了改變做出實(shí)踐的時(shí)候，往往就會(huì)發(fā)現(xiàn)一條新大路。同樣還有加不加分號(hào)的問題。

現(xiàn)在回過頭來再看，前端在整個(gè)系統(tǒng)層面擔(dān)任的角色至少應(yīng)該是整個(gè)視圖 View 層面的。視圖層面的技術(shù)更接近軟件系統(tǒng)的上層，更感性。感性的東西就是說一個(gè)顏色，我覺得好看，他覺得不好看，完全屬于個(gè)人情感訴求。所以前端更注重與 UI、交互 以及整個(gè)產(chǎn)品層面需要解決的問題。優(yōu)秀的前端必然要具備敏銳的產(chǎn)品洞察能力。

當(dāng)然這還只是前端最基礎(chǔ)的職責(zé)所在。同時(shí)前端做為最接近產(chǎn)品的技術(shù)角色，技術(shù)才是前端真正的硬實(shí)力。

大約在去年一年的時(shí)間，我的崗位從前端轉(zhuǎn)向了后端 Java 程序員的角色。雖然只做了一年的 Java 程序員，但是對(duì)我自身的技術(shù)提升而言是最多的一年。大家可能普遍的認(rèn)為后端轉(zhuǎn)前端比較容易，前端轉(zhuǎn)后端會(huì)有門檻，實(shí)際上根據(jù)我自己的體驗(yàn)來講并非如此。

Java 這門語言是商業(yè)化、成熟度特別高的語言。無論是語言本身，還是周邊框架、工具都有一套非常成熟且層次分明的系統(tǒng)化抽象。如果你有兩、三年的編程經(jīng)驗(yàn)，突然讓你上轉(zhuǎn)寫 Java 是非常容易的一件事情，尤其是寫 Java web。Spring 框架已經(jīng)為程序員屏蔽了很多復(fù)雜問題，而且已經(jīng)事實(shí)上成為了各大互聯(lián)網(wǎng)公司的主流框架選型。

我特意按我自己的學(xué)習(xí)線路繪制了一張 Java 版的程序員學(xué)習(xí)線路，僅供參考：

我們可以清楚的看出來 Java 構(gòu)建的整個(gè)體系最大的特點(diǎn)：它是漸進(jìn)式的，一步一步地給開發(fā)者建立正向的引導(dǎo)。

當(dāng)我處在在 應(yīng)用層 階段的時(shí)候，我需要關(guān)心的只是一些概念，方法，具備基礎(chǔ)了以后就可以借助 Spring 框架入門，入門后就可以研究源碼，你會(huì)發(fā)現(xiàn) Spring 的本質(zhì)核心類 DispatchServlet，從此 Servlet 就出現(xiàn)在了你的視野。我以前上學(xué)時(shí)理解不了 java 中 Servlet 的概念，后來參加了工作又學(xué)些了 Python，再次看到 Java 中的 Servlet 的時(shí)候瞬間就明白了它就是 Python 中的 uwsgi，就是一種接口，將編程語言和服務(wù)器網(wǎng)關(guān)鏈接起來的一種規(guī)范。

然后你就可以順利進(jìn)入下一環(huán)節(jié)，服務(wù)器/通信。這里你會(huì)發(fā)現(xiàn)整個(gè)網(wǎng)絡(luò)編程的核心 Socket，同樣以前上學(xué)的時(shí)候沒理解 Socket 的概念，繼續(xù)學(xué)習(xí)后你就會(huì)明白 Socket 其實(shí)就是操作系統(tǒng)提供給編程語言的一種能力，有了它就可以建立服務(wù)器與客戶端之間的通信。在這一環(huán)節(jié)中你會(huì)學(xué)習(xí)到網(wǎng)絡(luò)層 TCP/IP 協(xié)議，明白了 TCP/UDP 的區(qū)別， while (true) { socket.listen() } 建立 Socket 監(jiān)聽會(huì)有性能問題，此時(shí)你便進(jìn)入下一個(gè)抽象層次，操作系統(tǒng)和計(jì)算機(jī)原理。

為了解決「while true」監(jiān)聽連接的性能問題，你會(huì)去學(xué)習(xí)多線程技術(shù)，了解并發(fā)的概念。你可能總會(huì)聽到別人討論并發(fā)和并行的區(qū)別。繼續(xù)學(xué)習(xí)后，慢慢的你就會(huì)明白：并發(fā)多用來解決網(wǎng)絡(luò)IO（硬盤）的效率問題，而并行則是為了更好的利用多/核處理器（CPU）的問題。這時(shí)你會(huì)發(fā)現(xiàn)這個(gè)階段涉及到了很多的計(jì)算機(jī)硬件知識(shí)。內(nèi)存分配、CPU計(jì)算、IO 復(fù)用等等。

像 Spring 這種框架才能真正意義上被稱做 框架 ，因?yàn)樗粌H僅解決了軟件開發(fā)的問題，更重要的是 AOP/IoC 這類概念可以完全改變編程的一些理念。使用 Spring 開發(fā) web 應(yīng)用，聯(lián)合 Java 構(gòu)建出來的生態(tài)，整個(gè)開發(fā)流程就像呼吸一樣自然。

Java 構(gòu)建出來的軟件開發(fā)體系就像是把程序員放進(jìn)了一個(gè)一個(gè)的層次分明的小柜子里面，進(jìn)去了以后你根本不需要關(guān)注外界是怎么樣的，做好自己那部分工作就可以了。如果你對(duì)外界有興趣可以一點(diǎn)點(diǎn)的按圖索驥跳出你原來的小柜子。即保證精力專注的同時(shí)又建立起一套有秩序的提升曲線。這一點(diǎn)是別的語言體系沒有的。

實(shí)際上我在轉(zhuǎn) Java 之前對(duì) Java 有著不小的誤解，甚至轉(zhuǎn) Java 本身也不是我自己的想法。但當(dāng)你真正轉(zhuǎn)型成 Java 程序員后?？炊藬?shù)以百萬行記的代碼倉庫、維護(hù)過每秒好幾十萬的 QPS 項(xiàng)目、見識(shí)過百行的 SQL 的時(shí)候，你才會(huì)對(duì) Java 和軟件開發(fā)產(chǎn)生一種敬畏之心，才會(huì)對(duì)技術(shù)才有了更深層次的理解。

這時(shí)候再回過頭來看前端，看 JavaScript，才會(huì)發(fā)現(xiàn)它們之間的區(qū)別與特點(diǎn)。很多之前爭(zhēng)論的東西也就有了結(jié)論。

瓶頸

我相信從事前端工作稍微長(zhǎng)一點(diǎn)（5年以上）的人近兩年都會(huì)有一種感覺：前端似乎沒什么東西可以玩出花樣了。這是因?yàn)楹芏鄸|西都已經(jīng)成為了前端事實(shí)上的主流，以前前端沒有的基建慢慢的被完善。語言、框架、可視化、跨端、游戲、工具/自動(dòng)化/工程化 這些領(lǐng)域都在發(fā)展。

語言方面 TypeScript 必然是主流，無論你愿意與否，你都將不得不使用它來寫前端。框架方面 React 已經(jīng)是事實(shí)上的主流了，沒必要再做選擇題。打包工具 Webpack 也是一家獨(dú)大，雖然被很多人詬病，但是社區(qū)生態(tài)起來了，想改變就很難?？缍藨?yīng)用 Electron 也不用想了，VSCode 能做好你做不好那就不是選型的問題了。2D 游戲/繪圖方面 PixiJS 6 已經(jīng)在設(shè)計(jì)中了，3D 我個(gè)人認(rèn)為就先別玩了。

這些看似成熟的體系實(shí)際上還是有很多可以挖掘的東西。如果你不深入研究，或許會(huì)認(rèn)為過兩年這些技術(shù)就穩(wěn)定了前端就可以做到大一統(tǒng)的狀態(tài)。這個(gè)想法可能就過于天真了，我舉例解釋下它們各自的瓶頸：

前/客戶端框架的瓶頸

React（并不特指 React）雖然現(xiàn)在看起來是主流，但是它本身有很多問題是沒解決的，甚至可以說是無解的。React 的本質(zhì)只是一個(gè) UI Library，并不是框架 Framework。框架要解決的問題是系統(tǒng)層面的不是某個(gè)抽象層面的。用 React 寫過幾個(gè)項(xiàng)目以后你就會(huì)認(rèn)識(shí)到用 React 去寫大型項(xiàng)目是非常麻煩的事情，React 本身并不解決 SPA 應(yīng)用中數(shù)據(jù)流的問題，甚至沒解決狀態(tài)管理的問題（或者說狀態(tài)管理本來就是個(gè)偽命題？）。一個(gè)很簡(jiǎn)單的父子組件之間狀態(tài)共享的問題一直沒有成熟的解決方案，hooks 這種方案更像是拆了東墻補(bǔ)西墻。

而且現(xiàn)在 React 社區(qū)彌漫著一種崇尚函數(shù)式編程的邪氣，hooks 更像是一塊遮羞布。多數(shù)人用 hooks 的原因僅僅是不想使用 Class，因?yàn)?Class 很臃腫，function 更簡(jiǎn)單。當(dāng)然這個(gè)邏輯是沒問題的。函數(shù)確實(shí)簡(jiǎn)單，但是如果你把一個(gè)函數(shù)里面寫上幾百行的代碼，各種 hooks 用到飛起的時(shí)候，你才會(huì)回過頭來反思如何組織代碼。如果 Class 能以一種更好/更易于理解的方式去抽象那為什么不用呢？

后/服務(wù)端框架的瓶頸

前端框架如此，基于 Node.JS 的后端框架也好不到哪兒去，難道你真的想用 Express/Koa.js 去寫大型的后端應(yīng)用？這種量級(jí)的框架連 web 開發(fā)最簡(jiǎn)單的三層模型（ 模型、視圖、控制器）支持都不完整。當(dāng)然你可能會(huì)說小型框架本來就只關(guān)注某一方面嘛，視圖和模型層的東西可以用其它三方庫解決。是的，確實(shí)可以這樣，不過你不覺得 Node.JS 的第三方庫有點(diǎn)太多了嗎。正如 NestJS 在文檔中提到的一個(gè)問題一樣「很多 JavaScript 類庫都沒有高效地解決一個(gè)問題 架構(gòu) ?！筊eact/Vue/Express/Koa 這些都是相對(duì)獨(dú)立的點(diǎn)，沒有一個(gè)東西能把他們連接起來形成一個(gè)面，形成一種框架級(jí)別的體系。這就是架構(gòu)的問題。

這里多說一點(diǎn)，結(jié)合上面 Java 構(gòu)建出來的生態(tài)，對(duì)比 Node.JS 的話。我借用自己打過的比喻：如果你低頭看到的是 Node.JS，那么你抬頭未必能看見 Java。假如你從事前端開發(fā) 2，3 年遇到瓶頸，想轉(zhuǎn)學(xué) Node.JS，你會(huì)學(xué)習(xí) Exporess/Koa 這類框架，但是很快你就會(huì)發(fā)現(xiàn)一個(gè)嚴(yán)重的問題：沒辦法深入下去了。因?yàn)楫?dāng)你用 Express 寫完一個(gè)頁面后就面臨著各種技術(shù)上的盲點(diǎn)，會(huì)讓你無所適從。

我也嘗試?yán)L制一張我對(duì) JavaScript/Node.JS 或者說大前端體系理解的一張圖:

JavaScript 體系看似前后端通吃，客戶端、 服務(wù)端甚至桌面端皆有。但是最大的問題在于：沒有一個(gè)東西能給他們建立起關(guān)系并發(fā)展成為一種體系。

插播一條娛樂看點(diǎn)，前兩天寫 Ruby on rails 框架的作者 DHH 發(fā)推并配圖：

大意如下：

現(xiàn)在的年輕人在 web 開發(fā)的時(shí)候是這樣的嘛？底層邏輯、純手寫連接池 + 純手工 SQL、配置文件都放在了一起。天哪?。ń貓D中使用的式TJ大神寫的 Express 框架）

然后 TJ 大神也回復(fù)了：

大意如下：

只有菜鳥玩家才能寫出干凈、簡(jiǎn)潔、高性能（黑 Ruby 性能）、見名知意的 SQL，而不是去寫一個(gè)有15層的抽象。

兩者的推特對(duì)話挺有意思，大家娛樂一下。

TypeScript 語言的瓶頸

TypeScript 也主流，但是持續(xù)關(guān)注 TS 到現(xiàn)在，我發(fā)現(xiàn) TS 也遇到了瓶頸，這個(gè)瓶頸不僅來自于 TS 的設(shè)計(jì)目標(biāo)與理念，更多的還是社區(qū)及 TC39。TS 的設(shè)計(jì)初衷是 JavaScript 的超集，由于本身要編譯成 JS，這一點(diǎn)本質(zhì)上限制了 TypeScript 的方向，設(shè)計(jì)者對(duì)于添加一個(gè)新特性會(huì)非常謹(jǐn)慎，一者怕與 TC39 ES proposal 沖突，二者要考編譯到不同版本 JavaScript 的兼容性問題。以至于現(xiàn)在 TS 新的語言特性只會(huì)跟進(jìn) TC 39 發(fā)布的最新 ES proposal。但是我個(gè)人對(duì)于 TC 39 的效率及未來持懷疑態(tài)度，decorator 的提案一直還處于 Stage 2 的階段，像這種其它語言都成為標(biāo)配好幾年的事情，現(xiàn)在 JavaScript 社區(qū)還在草案（stage-2）階段。

在這個(gè)問題上我認(rèn)為其實(shí)也很好解決，開個(gè)腦洞：如果微軟想借助編程語言一統(tǒng)瀏覽器和客戶端是沒有什么不可能的。并入 TC39 組織，開發(fā)真正屬于 TypeScript 的原生引擎，奉天子以令不臣的方式也未嘗不可。

近幾年 Microsoft 對(duì)于開源的投入是肉眼可見的，微軟要發(fā)力我相信很多東西都會(huì)有翻天覆地的變化。

打包工具的瓶頸

Webpack/Babel 就更不用說了，主流中的主流。但是也是問題最嚴(yán)重的一個(gè)。Webpack/Babel 的流行恰恰從反面證明了前端的基礎(chǔ)設(shè)施有多么的爛?，F(xiàn)在國外網(wǎng)友老天天叫喊著 Webpack/Babel is eval 也是挺值得深思的。我們引入了一個(gè)新工具來解決問題，卻又在不經(jīng)意之間產(chǎn)生了新問題。

前端構(gòu)建工具問題的本質(zhì)還是在于 Node.JS 的包管理工具的設(shè)計(jì)。這一點(diǎn)在 Node.JS 的作者 Ryan Dahl 關(guān)于 Deno 演講《10 Things I Regret About Node.js》中也有過「官方」的承認(rèn)。我相信任何一個(gè)實(shí)現(xiàn)過構(gòu)建工具的人都被 Node gyp 打敗過。node-sass, fsevent 的痛不必細(xì)說。更不用說萬年被黑的 node_modules 了，你根本不知道一個(gè)簡(jiǎn)單的 npm install 命令會(huì)導(dǎo)致安裝成千上萬個(gè) npm 包被安裝到你的機(jī)器上。

當(dāng)然每種編程語言對(duì)應(yīng)的包管理工具都要解決依賴問題，而且這是一個(gè)普遍的問題，腳本/解釋型編程語言尤為突出，Python/Ruby/PHP 都有這些類似的問題。或許 Go/Rust 這種把源代碼編譯打包成單個(gè)可執(zhí)行文件的方式才是好的解決方式。

未來

從前人們總是抱怨 JavaScript 這門語言，黑它、諷刺它。但是我看到的是它在一點(diǎn)點(diǎn)變好。不僅是語言層面逐步完善，工具鏈生態(tài)日趨成熟，使用它的也人越來越多。大家對(duì)它的關(guān)注程度也在提高，整個(gè) JavaScript 開發(fā)者的水平也在向更高更強(qiáng)的方向發(fā)展。生存環(huán)境只會(huì)淘汰那些老舊不再進(jìn)化的事物，能適應(yīng)變化的才會(huì)永存。

JavaScript 這門語言有兩個(gè)其它 任何 編程語言都不具備的優(yōu)點(diǎn)：

1. 幾乎 無所不在 且不用安裝，有瀏覽器就有 JavaScript。腳本語言意味著它能被嵌入到任何宿主環(huán)境中去：Nginx、Native應(yīng)用、硬件編程、物連網(wǎng)、嵌入式 都有它的身影
2. 這門語言對(duì)于技術(shù)的更新迭代有著強(qiáng)大的 適應(yīng)能力 。JavaScript 本身的更新迭代速度導(dǎo)致它進(jìn)化速度很多，語言上的新特性會(huì)很快被運(yùn)用到生產(chǎn)環(huán)境。相比 Python 而言，這簡(jiǎn)直是做夢(mèng)，Python 2 到 3 的轉(zhuǎn)換沒人能看到真正的時(shí)間表。

當(dāng)下的前端開發(fā)狀況不由得讓我我想起蘇東坡《晁錯(cuò)論》中的一段話：

天下之患，最不可為者，名為治平無事，而其實(shí)有不測(cè)之憂…

最大的問題在于，有些事物，從表面上看著平淡無奇，但實(shí)際上底層暗流涌動(dòng)，似乎每一時(shí)刻都有著巨變的可能性。這也是前端開發(fā)最有趣也最有潛力的地方。

作為一名新時(shí)代的前端開發(fā)者，就是要在這看似風(fēng)平浪靜的表面之下，找到一些真正的突破點(diǎn)，興許只是一個(gè)簡(jiǎn)單的想法，順應(yīng)時(shí)勢(shì)然后造就出不斐的成就也說不定呢。

無論是前端還是后端、國內(nèi)還是國外，技術(shù)才是真正的核心競(jìng)爭(zhēng)力，只有技術(shù)革新才能提高生產(chǎn)力，而對(duì)于我們程序員來講，編程則是唯一能提升硬實(shí)力的方法。只要你心中充滿了熱情，堅(jiān)持下去總會(huì)走出一條自己的路子。

分享一段小經(jīng)歷

我在 2018 年有幸參加了 TypeScirpt 的推廣大會(huì)，TypeScript 的作者 Anders Hejlsberg 親自主講。一位將近 60 歲的程序員在講臺(tái)上滔滔不絕的講技術(shù)方案，TS 的設(shè)計(jì)理念。你真的很難想像這樣一位處于「知天命」階段的老頭子（實(shí)際上很年輕）講的東西。

[[325717]]

QA 環(huán)節(jié)有個(gè)年輕小伙問到 Anders「在中國做程序員很累、很難應(yīng)該怎么堅(jiān)持下去（類似這樣的描述，細(xì)節(jié)記不清楚了）」的問題。

Anders 幾乎毫不猶豫的說出了「Passion」這個(gè)單詞。我瞬間就被打動(dòng)了。因?yàn)樵诖酥拔覍?duì)于「激情」這個(gè)詞的認(rèn)識(shí)還停留在成功人士的演講說辭層面，當(dāng) Anders 親口說出 Passion 一詞的時(shí)候，讓人感覺真的是一字千金。

直到現(xiàn)在 Anders 還做為 TypeScript 的核心貢獻(xiàn)者為它提交代碼，到處奔走為 TypeScript 宣傳。

我們?cè)倩氐角岸?，那么未來的前端到底?huì)發(fā)展成什么樣？長(zhǎng)期而言充滿了未知數(shù)，誰也沒法預(yù)測(cè)，但是短期來講我比較關(guān)注幾個(gè)東西：

• ESBuild ：一個(gè)極快的 JavaScript bundler。這個(gè)工具可以說是真正的「Game changer」。同樣是一個(gè)打包任務(wù)，它快到讓你沒反應(yīng)過來就完成任務(wù)了。ESBuild 使用 Go 語言編寫，實(shí)現(xiàn)了整套 并行的 ES 解析器、代碼生成器，作者是 Figma 的 CTO（是的國外的 CTO 是要寫代碼的）。最近更新很頻繁，Vue 新的構(gòu)建工具也會(huì)基于它來做 TS 部分的打包功能。
• Deno ：一個(gè)安全的 JavaScript & TypeScript 運(yùn)行時(shí)。Deno 的方向充滿了可能性，未來 deno 不僅僅可以做 JS 后端，還能和 Rust 打通，給JS注入一些原生 native 的能力，然后 Webasmbly, webGL 之類的技術(shù)都變成了可能，1.0 正式版發(fā)布日期也快到了。
• Figma ：一個(gè)在線版的 Sketch，雖然功能還沒有 Sketch 強(qiáng)大，但是已經(jīng)有了設(shè)計(jì)界面的基本能力。關(guān)鍵還在于它的整個(gè)實(shí)現(xiàn)都是基于 web 技術(shù)，底層 C++ 實(shí)現(xiàn)圖形的渲染、繪制，前端通過 Webasmbly 與瀏覽器 Canvas 交互，做到了讓用戶在瀏覽器端體驗(yàn)到了 Native 軟件能力。像 AutoLayout 這種功能在用戶體驗(yàn)上就是顛覆式的，使用的時(shí)候它很自然，沒有什么存在感。但是用了就回不去了。

如果你仔細(xì)研究一番，上面的這些新鮮東西，都是起源于前端，但又不把視野局限在前端?；蛟S這就是前端未來的發(fā)展方向吧。