哪些技術(shù)會決定前端開發(fā)者的未來發(fā)展？

2019年下半年即將到來，上半年狂風驟雨般的裁員浪潮讓每一位從業(yè)者背脊發(fā)涼，在經(jīng)歷了五六年黃金發(fā)展期之后，前端開發(fā)這個行業(yè)似乎也進入了轉(zhuǎn)折點。

我一邊聽開發(fā)者在網(wǎng)絡(luò)上抱怨工作難找，前端開發(fā)早已經(jīng)飽和了，又在另一邊聽大廠的朋友們抱怨，招了很久的人，四處出擊卻填不滿HC，前端人才市場就是這么充滿了矛盾與反常。

其實仔細想想，出現(xiàn)上述的情況很容易理解，實際上前端開發(fā)單純從數(shù)量上已經(jīng)飽和了，所以大量的初級前端工程師找不到活干，但是從另一方面，高級前端工程師依然是鳳毛麟角，高級崗的HC永遠是不飽和的。

前不久民工叔發(fā)的動態(tài):

目前前端人員的分布是金字塔形的，而且是底部比較長的金字塔形狀:

所以進階是大部分前端開發(fā)必須要面對的事情，現(xiàn)在已經(jīng)不是能寫幾個頁面就能找到工作的時代了，只有往上進階才能保持職業(yè)競爭力，否則我們誰都不能保證下次裁員潮來臨的時候，我們會不會成為沙灘上裸泳的人。

我對前端技術(shù)的思考方式

前端社區(qū)是非?；钴S的社區(qū)，幾乎每過一段時間都會有新的技術(shù)或者新的開發(fā)方式變成了熱點，因此前端開發(fā)者才會有了『學不動了』的梗，以及畢竟丟人的Deno留言事件。

以我自己為例，因為想自己開發(fā)一個APP，所以面臨技術(shù)選型，也面臨將來要投入大量時間選擇學習的技術(shù)，擺在我面前的有三個選項：

• Flutter跨平臺技術(shù)

• RN跨平臺技術(shù)（WEEX除了阿里生態(tài)外，很少用的）

• 原生技術(shù)

到底選擇哪一個技術(shù)既能滿足開發(fā)APP的需求，又值得投入時間進行學習呢？

如果你去知乎或者其他技術(shù)類的社區(qū)去問，絕大多數(shù)的回答是Flutter（雖然從回答來看很多答主似乎都沒用過Flutter），F(xiàn)lutter作為正式發(fā)布才剛剛半年的新技術(shù)已經(jīng)席卷了整個大前端圈子，成為了當之無愧的關(guān)注熱點，真是佩服谷歌的布道能力。

關(guān)于Flutter的事情我思考了很久，也用它快速開發(fā)了一個demo，它有很吸引人的地方：

• 聲明式UI這跟react很像，比Android 那種UI編程方式先進太多（筆者很早之前寫過一個Android APP，那編碼體驗不談了）

• 更徹底的跨平臺，直接調(diào)用Skia繪圖引擎進行組件渲染，比RN更加底層，它的理念更像是游戲。

• 更大的潛力，有消息稱Flutter是谷歌新操作系統(tǒng)的第一指定框架，這意味著你可能搭上這新系統(tǒng)的風口。

這門技術(shù)確實很吸引人，加上社區(qū)各個會Flutter不會Flutter的人義務(wù)宣傳下，我甚至快決定好好學習一下Flutter了。

但是，大家有沒有想過，通過學習Flutter，你的技術(shù)就提升了嗎？

很多人第一反應(yīng)是『當然了，學了一門新技術(shù)，學了一門新語言，難道技術(shù)不是提升了嗎？』。

但是我覺得并沒有，我其實依然在原地打轉(zhuǎn)，一個Java開發(fā)者學會了用Ruby增刪改查并不能代表能力提高了，一個前端開發(fā)者用RN或者Flutter開發(fā)了簡單的APP也不能說明水平提高了，只不過是用另一種語言再寫了一遍UI而已，會用三種框架寫頁面，并不是什么高技術(shù)含量的事情，會三種不如深入一種。

Flutter跟RN一樣，想玩得轉(zhuǎn)必須深入到原生開發(fā)中，因為這兩個技術(shù)都不是真正的跨平臺，他們僅僅是UI跨平臺，如果你僅僅學一個Flutter寫寫UI，意義不大，也不存在能力的提升。

我們或者再功利一點地思考，就算你學會了用Flutter寫UI又怎么樣呢？你們公司內(nèi)部有Flutter項目嗎？即使有輪得到你施展拳腳嗎？畢竟你沒有原生平臺的知識儲備，僅僅寫個UI又有什么呢？

其實，這個例子說了這么久，我只是在說兩件事情：

• 我們有時候看似在學很多技術(shù)，其實這些技術(shù)并不能提升你，但是給你造成了『我學了新東西能力提升了』的自我感覺偏差

• 不要盲目追尋社區(qū)的熱點，很可能撿了芝麻丟了西瓜，要仔細思考這門技術(shù)對于你本身是否有提升，而不是被布道師們『洗腦』

我以這種思考模式仔細研究了近一段時間熱點的技術(shù)，有幾門技術(shù)我可以比較確信在未來會在前端開發(fā)領(lǐng)域大展拳腳。

TypeScript

我從2017年就開始使用TypeScript了，可以說正當時，在使用過程中踩了很多坑，也總結(jié)出很多經(jīng)驗，知乎上的問題『你為什么不使用TypeScript？』中的獲得最高票數(shù)回答就是筆者本人。

在2019年的年中，我可以非常確信TypeScript會在一年內(nèi)大規(guī)模流行，怎么定義大規(guī)模流行？

超過30%基于前端框架的新項目會以TypeScript為主要語言開發(fā)。

原因我總結(jié)了三點。

逐漸統(tǒng)治開源社區(qū)

大量重量級前端開源項目采用TypeScript開發(fā)，包括不限于：Angular、VScode、Vue3.0、Rxjs、TypeScript（對，它自舉）、Mobx、deno、Antd，而且這個趨勢越來越明顯，包括Facebook自家的Jest也宣布從flowType轉(zhuǎn)向TypeScript。

這些重量級的開源項目有非常強得帶動作用，我不止一次見過有的前端開發(fā)者說，為了看懂Antd的源碼，特地學了TypeScript。

可以說，TypeScript的開源生態(tài)已經(jīng)非常完善了，公司完全可以放心大膽得進行TypeScript化開發(fā)。

TypeScript是真正解決生產(chǎn)力問題的技術(shù)

請問前端開發(fā)中，引起錯誤的最多的三種報錯是什么？

你不會想到，是：

• Uncaught TypeError: Cannot Read Property

• TypeError: ‘undefined’ Is Not an Object (evaluating...)

• TypeError: Null Is Not an Object (evaluating...)

居然是三種非常非常低級的錯誤，原因就是JavaScript是動態(tài)語言，只有運行時才會報錯，這些低級錯誤在類型定義完整的TypeScript中不會發(fā)生，這就是TypeScript的優(yōu)勢之一，編碼時就能規(guī)避大量的類型錯誤。

TypeScript完整定義接口，可以減少非常多的溝通成本和文檔編寫成本，最好的文檔就是類型，除此之外，有了TypeScript的支持前后端的協(xié)作也會非常方便，有了TypeScript我們完全可以開發(fā)一個工具把后端Java Swagger的信息映射到TypeScript中，方便我們?nèi)?shù)并最大程度規(guī)避錯誤。

現(xiàn)在已經(jīng)有了這么一款前端取數(shù)庫pont.

總而言之，TypeScript解決了前端的兩大問題，規(guī)避錯誤和提升效率。

阿里 MidwayJs Team的負責人在GMTC上就說到過『 TypeScript，來幫助我們解決這些質(zhì)量，習慣，方法上的問題，就拿 midway 團隊來說，自從使用了 TypeScript，質(zhì)量提升的非常明顯，平常需要測試很久的代碼，幾乎不會出現(xiàn)低級的問題，反而暴露出的大多都是邏輯問題?！徊⑻岬健憾衲?，我們希望新應(yīng)用全量使用 TS?！?/p>

Vue3.0會是TypeScript大規(guī)模普及的導(dǎo)火索

Vue3.0將在下半年的發(fā)布，雖然尤雨溪確認Vue3.0支持JavaScript和TypeScript兩種語言，但是vue2.x那種殘疾級別的支持到現(xiàn)在原生支持TypeScript，勢必會引起大量以vue為技術(shù)棧的公司進行TypeScript化運動。

屆時三大框架都可以完美支持TypeScript，甚至其中有兩個是由TypeScript直接開發(fā)的，而vue在國內(nèi)的用戶量最多，也最能影響TypeScript在國內(nèi)的走勢。

而據(jù)我所知美團、餓了么等一大批vue技術(shù)棧的前端團隊也已經(jīng)大量實踐了TypeScript，至少在大廠層面，TypeScript已經(jīng)開始大規(guī)模普及了。

圖形技術(shù)

圖形技術(shù)不會在短時間內(nèi)席卷前端，也永遠不可能成為前端的熱門技術(shù)，但是卻是前端開發(fā)者進階必學的技術(shù)。

為什么說圖形技術(shù)不會在前端大火？

要火早就火了，今年年內(nèi)都要發(fā)布webGPU了，絕大部分前端連webgl1.x都搞不清楚，歸根到底是技術(shù)棧不匹配，前端開發(fā)和移動端開發(fā)雖然很大一部分工作是實現(xiàn)UI，但是這個實現(xiàn)方式幾乎都是調(diào)用宿主內(nèi)置組件，極少有用圖形接口畫UI的情況。

為什么又說是進階必備？

圖形技術(shù)可能是僅有的與前端有密切聯(lián)系的計算機底層技術(shù)了，因為所謂的UI就是靠圖形接口調(diào)用GPU繪制而成的，這樣就意味著掌握圖形技術(shù)就能更深度地定制UI。

未來的前端UI不僅僅是簡單的Input、Table、List等粗顆粒的組件構(gòu)成的，而是更加多元化、更加細粒度，就拿筆者最近研究的可視化大屏項目來說，它幾乎用不到任何傳統(tǒng)的前端組件，一部分2D組件是調(diào)用Canvas繪圖接口，一部分3D組件是靠webgl繪制而成。

今年下半年5G開始在國內(nèi)大面積鋪開，普遍的一個觀點是認為5G的到來會讓AR、VR等虛擬技術(shù)重新煥發(fā)生機，這些技術(shù)也無一例外不與圖形技術(shù)相關(guān)聯(lián)，畢竟你總不會認為在AR中繪制一個input組件吧。

從去年開始關(guān)注圖形技術(shù)，我也驚喜的發(fā)現(xiàn)跟一些前端專家們的觀點不謀而合。

一個是年初奇舞團的leader月影在知乎的回答：

另一個也是年初winter的前端技術(shù)預(yù)測：

編輯器領(lǐng)域技術(shù)

這里的編輯器指的是各種編輯器的總稱，例如：代碼編輯器（WebIDE）、圖形編輯器（在線的3d建?；蛘遬s）、文本編輯器等。

編輯器領(lǐng)域技術(shù)不會像TypeScript一樣蔓延到幾乎所有的前端團隊，但是一定是會在局部火起來的技術(shù)。

為什么說只會在局部火起來？

這是個非常小眾的領(lǐng)域，但是復(fù)雜度和重要性卻與日俱增，首先絕大部分公司的絕大部分業(yè)務(wù)場景中對編輯器的需求很小，其次，編輯器的通用性很大，每個網(wǎng)站的具體業(yè)務(wù)場景的實現(xiàn)千差萬別，但是說到用戶輸入的文本編輯器，那可能用的都是同一款開源軟件。

說完了局部，我們在談?wù)劄槭裁磿?，最重要的一點就是云端開發(fā)的普及，大量的開發(fā)者服務(wù)被移植到云上，包括最近比較火的FaaS、小程序服務(wù)等等，云廠商一方面為了給開發(fā)者提供更好的服務(wù)，比如開發(fā)FaaS的調(diào)試服務(wù)，所以需要定制符合自己業(yè)務(wù)的webIDE，另一方面也更重要，一個開發(fā)者的開發(fā)環(huán)境輕易是不會變的，webIDE就是這個環(huán)境，webIDE就是云廠商開發(fā)者爭奪戰(zhàn)的入口。

另一個原因就是，大規(guī)模的團隊十分需要將各個團隊的能力整合在一起，而整合開發(fā)的鑰匙就是IDE。

雖然很多公司招編輯器相關(guān)的工程師都是掛著前端的Title，但是普通的前端工程師如果沒有相關(guān)經(jīng)驗，完全拿不下這種場景，這就造成了雖然這是個小眾領(lǐng)域，但是人才卻很缺失的情況。

下圖為圓心在GMTC上展示的阿里前端委員會布局的四大方向：

談一談其它熱點技術(shù)

• Serverless

Serverless肯定會火，而且也是生產(chǎn)力上的直接提升，前端可以不考慮部署、運維、環(huán)境等場景，直接編寫函數(shù)來實現(xiàn)后端邏輯，可能以后人人都是所謂的全干工程師了。

但是為什么沒有重點拿來將，首先serverless的適用場景還比較輕量，他不是銀彈，現(xiàn)在的serverless熱在一定程度上夸大了它的實際作用。

還有一點，對于前端而言Serverless其實是工具，你只能拿來用，本身的開發(fā)需要云原生的專業(yè)開發(fā)者，所以前端根本無法深度參與，他反而把前端對node的要求降低了（因為只要會代碼，不需要后端知識），但是對于企業(yè)和團隊是好事，對于個人而言并不是非常有助于成長的一門技術(shù)。

• IOT

5G來臨，萬物互聯(lián)的說法又隨之而來，IOT會不會在5G時代火，我并不確定，但是前端在IOT上想大展身手我覺得這幾年內(nèi)看不到進展。

有人會說不是有人把js移植到嵌入式領(lǐng)域了嗎？是的，甚至三星還為IOT設(shè)備定制了js虛擬機。

IOT是低性能低功耗低內(nèi)存的設(shè)備，越是在這種場景下，低運行時高性能偏底層的編程語言越強大，可惜js與此恰恰相反，這門語言天生不適合IOT，而C語言卻如魚得水。

ps：我之前聽過一個專門搞IOT的技術(shù)專家說過，js最大的問題就是功耗，很多便攜式的IOT設(shè)備上js根本沒辦法商用（充電五分鐘，待機5秒鐘）

那為什么還有那么多人在炒js in IOT這個話題？

感興趣的可以聽Ruff的作者鄭曄的電臺采訪。

原因就是js開發(fā)者多。。。有技術(shù)難度的底層技術(shù)都會被專業(yè)的嵌入式開發(fā)者搞定，js開發(fā)者只需要寫業(yè)務(wù)即可，所以又回到關(guān)于Flutter的問題了，你在IOT寫業(yè)務(wù)比瀏覽器寫業(yè)務(wù)有啥技術(shù)提升呢？

當然了，從職場角度搞IOT還是有前途的，一旦IOT火起來，先進入這個領(lǐng)域的人可以更輕松地摘桃子，但是我個人不推薦現(xiàn)在就入坑，風險遠大于收益，如果真的對js in any感興趣，不如去研究js runtime，比如node和deno，這是真正有助于提升能力的技術(shù)。

• GraphQL

GraphQL已經(jīng)被炒了好幾年了，但是依舊動靜不大，不是技術(shù)本身又有問題，是這門技術(shù)嚴重損害了后端開發(fā)利益。

GraphQL對于前端開發(fā)者是真的好用，從此不用求后端大哥搞新接口了，完全可以自給自足，但是這個讓前端開發(fā)爽到天的技術(shù)，付出的代價就是大量的改造工作需要后端來做，后端團隊累死累活搞了GraphQL，得利最大的卻是前端，出了錯鍋得后端背，這種技術(shù)推動的阻力可想而知。

這門技術(shù)考驗的是跨團隊溝通協(xié)作能力，不是技術(shù)本身，當然很多時候前者比后者更重要，但是與本文主題不符，按下不表。

• AI IN FE

這幾年炒的最火的技術(shù)就是AI，雖然這個領(lǐng)域跟前端可以說沒有任何交集，但是依然有很多人想往這方面靠。

先說tfjs的問題，基于瀏覽器的深度學習框架，其實應(yīng)用范圍非常非常窄，筆者在調(diào)研的時候沒有發(fā)現(xiàn)什么有商業(yè)價值的案例，在瀏覽器中跑深度學習本來就很小眾，再加上js本身的性能問題和瀏覽器沒有支持GPU加速的API，導(dǎo)致tfjs更像是個殘次品，實際上一些前端團隊雖然在開發(fā)AI應(yīng)用，但是基本用的都是正宗TensorFlow。

目前算是比較靠譜的前端+AI的場景就是自動化UI，將設(shè)計師的設(shè)計稿自動生成UI組件，還原UI是非常機械重復(fù)性的工作，早日干掉還原設(shè)計稿可以充分解放前端，目前閑魚的大前端團隊已經(jīng)有相關(guān)的成果了。

前端就算涉及AI，也最多是停留在工具使用階段，也就是所謂的『調(diào)包俠』，當然，即使這樣你能幫助團隊解決生產(chǎn)力問題，那么已經(jīng)是大功一件了，建議有能力的同學可以布局一下這方面的技術(shù)，但是對于絕大多數(shù)人而言，玩轉(zhuǎn)深度學習即使是調(diào)參也是很遙遠的事情。

最后

這是筆者看完圓心的分享之后的一點感受，圓心的格局很高，談到的都是技術(shù)形態(tài)、技術(shù)影響力和技術(shù)生態(tài)，本文格局還很小，只停留在技術(shù)成長上，只不過對于當下的筆者這種小格局似乎更實用。