在寫這篇文章之前，我一直在思考該用什么的方式能講清楚前端為什么要向智能化方向切換的理由，真的反復(fù)思考很久，后來決定還是以我做前端的過去 10 年的所見所聞來做個解答吧，這樣讓大家也都更有些體感。
這段是我跟前端的結(jié)緣，想必很多人也跟我一樣，懵懵懂懂地就撞入了前端這個行業(yè)。
一腳入坑
我接觸前端，那還是 2010 年的時候，在那個時候最火的是 網(wǎng)絡(luò)三劍客 —— Adobe Dreamweaver、Adobe Flash、Adobe Fireworks。
這三款軟件都很熱門，第一款可以通過可視化編輯器拖拖拽拽、填填配配就可以搞定一張網(wǎng)頁，雖然上手起來概念眾多、也挺難用的，但至少是那個時代做網(wǎng)頁最牛逼的軟件了；
第二款是做 Flash 的，配備一門 ActionScript 的語言，當(dāng)時網(wǎng)上下載了不少大牛做的很極客的 Flash 網(wǎng)站源碼，不過代碼讀起來很吃力；
第三款是做海報的（因?yàn)楹髨D比較大、比較長，切割起來比較耗費(fèi)內(nèi)存，這款軟件速度比較快）和 Gif 動畫的，但我用的少，大部分時間都用 Photoshop CS4 來搞定。
雖說這三款軟件最火，但真正讓我入坑前端（那個時候還沒有“前端”這個稱呼，有的就是“切圖仔”）的理由，是因?yàn)槲蚁氘?dāng)一位網(wǎng)頁設(shè)計師。
當(dāng)時，想當(dāng)一位網(wǎng)頁設(shè)計師的理由有二：
軟件工程搞 Java、C++、C 真是挺枯燥無聊的，寫一段程序，還得編譯、部署，等上個兩三分鐘的，特別無語；而當(dāng)初接觸 Web 頁面開發(fā)時（當(dāng)時還是一位外教授課），發(fā)現(xiàn)網(wǎng)頁這東西很神奇，在一個 Text 文本編輯器里敲上幾行代碼，改個擴(kuò)展名，雙擊頁面就展示出來了，這種所見即所得的美的視覺沖擊力，當(dāng)時讓我向這個方向上蠢蠢欲動，埋下了禍根??。
在教育網(wǎng)慶幸地就是可以翻墻看了不少國外的網(wǎng)站，當(dāng)時最大的感受就是美觀、大氣、留白充足，而國內(nèi)的網(wǎng)頁哪里是網(wǎng)頁，UI 的設(shè)計簡直齪的不要不要的，沒什么美感，全是一堆文字 和 框，外加一堆閃來閃去的 gif（比如那個 “New”）堆砌，尤其是教育網(wǎng)的官網(wǎng)，那丑的簡直不要不要的了。再加上當(dāng)時的 QQ 空間很火，可以 DIY 自己的空間，但還是感覺不大氣，所以當(dāng)時就想著自己做出一款比較高端大氣上檔次的網(wǎng)頁??。
大學(xué)期間，雖然自己學(xué)設(shè)計做網(wǎng)頁這個想法被身邊同學(xué)嘲笑說這應(yīng)該是專科同學(xué)才去搞的東西，但的確還是堅持下來了。平時自己除了讀專業(yè)課程和完成課程實(shí)踐以外，就是在寢室、在圖書館、在選修課、實(shí)驗(yàn)室里抱著一堆影樓的 P 圖視頻寶典和一本影印版的厚厚的設(shè)計資料度過的。當(dāng)時自學(xué)了 Photoshop ，也學(xué)會了設(shè)計中的三原色原理，并應(yīng)用在班級日常校園種海報設(shè)計、照片美化等工作上，如今拿著單反拍個照 P 個圖的本領(lǐng)也都那個時候積累下來的。
再然后就是在校園里找了個實(shí)驗(yàn)室的項(xiàng)目，跟一伙人做一個外賣網(wǎng)站，自己擔(dān)任網(wǎng)頁的開發(fā)部分。老實(shí)說那個時候?qū)Ψ蕉疾恍湃挝夷芨愣ňW(wǎng)頁開發(fā)，畢竟我還是初級的小白。所以自己那個時候啃 W3C，在網(wǎng)上邊學(xué)邊做，雖然當(dāng)時有個不錯的 jQuery 的框架，但自己還是純手工用 HTML4、CSS、Javascript 擼出了級聯(lián)地域菜單選擇器，而且 UI 也是自己設(shè)計的，頓時信心感爆棚，所以一發(fā)不可收拾的一個項(xiàng)目一個項(xiàng)目地走向了網(wǎng)頁開發(fā)或者叫切圖仔這個行業(yè)。
這大概就是我與前端埋下的不解之緣吧，算是一腳踏入了前端這個行業(yè)。
兩腳入坑
而要說真正接觸“前端”這 2 個字的時候，那還是在面試淘寶時面試官向我提起的。雖然當(dāng)時還是聽不懂前端到底是干嘛的，但一聽面試官說能跟設(shè)計師一起工作，而且未來想做設(shè)計師也可以內(nèi)轉(zhuǎn)，我就沒有再半點(diǎn)猶豫，當(dāng)時一天就搞定了所有面試流程，簽下了淘寶前端開發(fā)工程師的 Offer ，從此就兩腳都踏入了前端這個行業(yè)了??。
當(dāng)你真正從校園出來，沉浸于工作之后，就會發(fā)現(xiàn)時間過得速度遠(yuǎn)比你在學(xué)校里快了不止一倍，每時每刻都覺得時間不夠用、業(yè)務(wù)完全做不完，感覺自己的時間都給了工作，我過去也在反思這個原因到底是什么，后來也漸漸想明白，這種快本身與互聯(lián)網(wǎng)的發(fā)展相輔相成的，從 2G 到 3G，再到 4G，以及接下來的 5G、6G……，正因?yàn)榛ヂ?lián)網(wǎng)大潮的發(fā)展，以及我們這些推潮者的存在，我們的時間變快也就變得正常了。我知道很多人不理解，但在這個圈子里的人都會理解或有同樣的聲音存在。就比如以前端發(fā)展的這 10 年為例，你就會深有體會了。
以下就是詳細(xì)介紹前端發(fā)展的這黃金 10年，有興趣的讀者可以細(xì)讀，沒有興趣的可以通過這點(diǎn)概述繞過：前端在最初，僅僅是為了完成一張網(wǎng)頁的開發(fā)，到后來，要能在同時完成 5 張、10 張甚至更多張頁面的開發(fā)，對前端的挑戰(zhàn)變大，所以前端作業(yè)內(nèi)容從單純的網(wǎng)頁開發(fā)，拆分成模塊式開發(fā)，拆分到前后端分離，過渡到可視化搭建系統(tǒng)等等，職能范圍也從網(wǎng)頁開發(fā)逐漸過渡到后端開發(fā)、全棧開發(fā)，領(lǐng)域范圍也從網(wǎng)頁開發(fā)細(xì)分到 PC 端開發(fā)、移動端開發(fā)、游戲/互動開發(fā)、Nodejs 開發(fā)、架構(gòu)工程開發(fā)等，工程內(nèi)容也從一段 jQuery 代碼就搞定的階段發(fā)展到前端也需要構(gòu)建、打包、集成、測試、灰度等高度工程體系化的復(fù)雜程度。但生產(chǎn)力還以人肉為主，互聯(lián)網(wǎng)前端行業(yè)還是勞動密集型作業(yè)方式。
階段一：刀耕與火種 & 野蠻生長
2010 年的前端，IE6 還盛行，jQuery 是老大，YUI 雖然也不差，但用的人畢竟沒有 jQuery 多。有個比較牛逼的工具叫 Firebug，這算是給前端的最大福利。這個時候的前端，在我看來應(yīng)該還算刀耕火種階段，雖然有 Dreamweaver 這樣的網(wǎng)頁可視化編輯工具，但產(chǎn)生的無用代碼量真是挺多了，而且對接數(shù)據(jù)比較麻煩，維護(hù)成本也不低，在當(dāng)時的網(wǎng)絡(luò)條件下，用它的人可能也不少，但我一直不用它。
階段二：模塊化開發(fā) & 框架升級
2011 年，來到阿里實(shí)習(xí)之后，發(fā)現(xiàn)天貓（當(dāng)時還叫淘寶商城）的頁面的確很高端、大氣，而且也的確跟設(shè)計師在一起工作（當(dāng)時還叫 UED），很興奮。當(dāng)時的前端規(guī)模不大（算上外包，15~20 人左右），YUI 在公司還比較盛行，KISSY 開始展露頭角，看到前人大牛寫的代碼有條有理、的確非常膜拜，所以基本那半年的實(shí)習(xí)生活里大部分周末都泡在公司里或者加班或者自己學(xué)習(xí)前人的東西。與此同時，公司內(nèi)還有一款非常牛逼的產(chǎn)品叫 TMS ，可以通過模塊化以及模板化的思想，分分鐘就可以搭出一張頁面來，簡直牛逼的不要不要的，那個時候淘寶商城的雙 11（雖然很多人當(dāng)時還把雙 11 當(dāng)光棍節(jié)）活動頁面就是用這款大殺器搭建完成的。用模塊化搭建的思路來解決頁面批量生產(chǎn)的問題，這個思路在當(dāng)時業(yè)界也算領(lǐng)先，而且這個思路一直延續(xù)到今天。所以如果阿里有個產(chǎn)品歷史博物館的話，TMS 絕對位列其中。
階段三：瀏覽器加持 & 富體驗(yàn)化
伴隨著瀏覽器大戰(zhàn)，瀏覽器內(nèi)核技術(shù)在向前發(fā)展（有興趣的同學(xué)可以在網(wǎng)上自助看看瀏覽器的內(nèi)核發(fā)展史，比如《全面了解瀏覽器（內(nèi)核）發(fā)展史》），IE 逐漸跟不上 Firefox 、Safari 和 Chrome 的節(jié)奏。后起之秀 Chrome 非常關(guān)注 JavaScript 的引擎性能，覺得可以再提升 10 倍，所以自研一款高性能 JavaScript 引擎，名叫 V8，以 BSD 許可證開源，Chrome 在瀏覽器家族內(nèi)的地位如日中天。給前端配套的 debug 工具鏈更加完善，通過控制臺可以完成代碼調(diào)試、性能檢測、資源檢測、網(wǎng)絡(luò)檢測、DOM 結(jié)構(gòu)檢測等等諸多工作， Chrome 在前端的眼里簡直可以說是一款瀏覽器走天下，IDE 什么的完全通通不用。
因?yàn)?Chrome 的加持，前端的研發(fā)效能有所提升，外加 HTML5 + CSS3 誕生和瀏覽器對它的爭先支持， Web 頁面的性能體驗(yàn)也逐漸上了一個臺階，在網(wǎng)頁上可以做的技術(shù)嘗試也開始展露，如網(wǎng)頁特效/動畫、網(wǎng)頁游戲。
階段四：前后端分離 & 工程完善
而這個思想的提出時機(jī)恰好是在 NodeJS 和 NPM 生態(tài)初步建立的階段，阿里借助 NodeJS 做前后端的分離嘗試，在后端諸多質(zhì)疑聲中，干掉了 PHP、廢棄了 Java 的 Web 容器，一路拿下了前端在 Web 容器上的主動權(quán)。前端在 NodeJS 生態(tài)上，也開始有 express、koa、egg、begg 這樣的 Web 應(yīng)用框架開源，也開始有了借助 NodeJS 完成的工程腳手架套件（如 webpack ），同時也衍生了一個新的工種 NodeJS 開發(fā)工程師，基本阿里的所有 Java 中間件生態(tài)，在 NodeJS 生態(tài)上也有對應(yīng)的一份了。
前后端分離，讓前端主導(dǎo) Web 容器，帶來的直接益處就是前端可以從 Client 和 Server 兩端進(jìn)行一體化的生產(chǎn)工程設(shè)計，讓前端的頁面加載性能達(dá)到極致化。當(dāng)然，前端職能的拓寬，也給前端帶來了額外的工作負(fù)擔(dān)，所以如果沒有充分人力準(zhǔn)備的部門，輕易不會嘗試負(fù)責(zé) WebServer 端，畢竟運(yùn)維需要成本。但慶幸的是，隨著 docker 容器化技術(shù)的發(fā)展和云基礎(chǔ)設(shè)施運(yùn)維能力的發(fā)展，從 IaaS 發(fā)展到 PaaS，再到 SaaS，服務(wù)端的運(yùn)維成本大幅度降低，所以前端運(yùn)維 WebServer 的成本就降低很多。
后話：如今發(fā)展到 FaaS 階段，基本就是 Serverless 化的，運(yùn)維基本對上透明，上層更加感知不到。
當(dāng)然，前后端分離并沒有對前端的研發(fā)效率上有太多的改觀，倒是在前端工程體系上更加完善和健全。以前的前端可以被叫頁面仔，但這個階段前端已經(jīng)不再是了，因?yàn)榍岸说墓こ腆w系（如 IDE、研發(fā)、構(gòu)建、打包、集成、測試、灰度、生產(chǎn)服務(wù)等等）不比 Java 的差多少。
階段五：終端碎片化 & 技術(shù)洗禮
2013 年，移動端興起，阿里 All in Mobile，移動端瀏覽器的發(fā)展勢弱，趕不上 App 的用戶體驗(yàn)，多年在 PC 時代沉淀下的技術(shù)產(chǎn)物發(fā)現(xiàn)在移動端弱網(wǎng)的環(huán)境下難以應(yīng)對，Mobile First 技術(shù)戰(zhàn)略之下，很多基建又得從移動端開始重新設(shè)計。
比如：kissy 在移動端的 mini 版 kimi，但后來也因?yàn)?kissy 在業(yè)務(wù)前端的口碑形象下滑的厲害，以及社區(qū)內(nèi)有 RN（React Native）和 Vue 的興起，所以 kissy 的生態(tài)也在時代的車輪下漸漸消失。
再比如：上文提到的 TMS 系統(tǒng)，因?yàn)樗鼘σ苿佣说牟贿m應(yīng)，導(dǎo)致它在時代的車輪下漸漸消失，被新的產(chǎn)品替代，支撐住移動端的網(wǎng)頁搭建。
隨著 3G、4G 的發(fā)展和 iOS 和 Android 手機(jī)在市場的普及量大增，PC 業(yè)務(wù)主戰(zhàn)場也逐漸過渡到移動端。前端的思維模式由 PC 轉(zhuǎn)向了移動端，并向 App 的用戶體驗(yàn)看齊。移動端的 HTML5 協(xié)議支持不完善，前端的生產(chǎn)配套不全，Android 的屏幕碎片化，所以那個時候的前端開發(fā)移動端頁面適配的痛苦要遠(yuǎn)遠(yuǎn)超過 PC 時代。
階段六：數(shù)據(jù)化驅(qū)動 & 框架之爭
不過，慶幸地是有 Angular、React、Vue、RN （React Native） 這樣的 MVVM 框架出現(xiàn)，讓前端接受了數(shù)據(jù)驅(qū)動思想的洗禮之外，還借助 RN 完成了移動端的體驗(yàn)升級，包括后來的 Weex、Flutter。
在這個階段，前端開始有了終端的底層架構(gòu)組，開始構(gòu)思前端頁面在移動終端上的加載性能和用戶體驗(yàn)表現(xiàn)。前端在移動端的研發(fā)上在 Web 和 Weex 容器上來回遷移和猶豫，增加了技術(shù)選擇的負(fù)擔(dān)，而且相互間無法復(fù)用。
所以為了解決多端復(fù)用的問題，Weex 又借助生態(tài)上的 Vue 框架，打通 webview 和 weex 兩端，夢想著一套代碼跑天下。但現(xiàn)實(shí)中就是打臉的，兩種終端容器能力不對齊，相互制約，一套代碼寫得瞻前顧后。這個時候的前端，被終端技術(shù)折磨的苦不堪言。
但好在 Web 在移動端的發(fā)展越來越強(qiáng)，同時借助客戶端的一些能力加持（如 hybird、cache、prefetch 等），web 頁面的體驗(yàn)強(qiáng)到可以與 App 分庭抗禮。所以經(jīng)歷過煎熬的四五年時間，如今 web 的聲音已經(jīng)在移動端占主導(dǎo)地位。對應(yīng)的移動端框架也確定下來。
同時，2016 年，小程序的概念開始提出到上線，一種輕 App 的開放解決方案開始在國內(nèi)掀起浪潮，微信、支付寶、百度等一堆互聯(lián)網(wǎng)大廠（包括如小米、華為等的手機(jī)硬件廠商）在這個大潮之下分食。所以一種小程序的新 DSL 誕生在前端眼前，前端要兼顧 web 及各個廠商之間的 小程序 DSL，痛苦又翻倍增加。有痛苦就有人解痛，像 WePY 、 mpvue 、Taro 等小程序框架如雨后春筍，相繼出現(xiàn)（《小程序第三方框架對比 ( wepy / mpvue / taro )》）。
除了移動端，在 PC 的 C 端和中后臺業(yè)務(wù)上，分別該用什么樣的技術(shù)方案呢？要不要用 MVVM 框架呢？用React（包括 Preact）、Vue、Angular 具體哪個框架呢？
在經(jīng)歷過多方聲音的反反復(fù)復(fù)多年的爭吵下，最終總算確定了中后臺全部采用 React ，PC 的 C 端采用跟移動端一樣的同構(gòu)方案。雖經(jīng)歷過幾年的痛苦折磨期，但框架之爭總算平靜下來，前端的目光開始關(guān)注更上層的東西組件化物料（如 AntD、Fussion、ICE 中后臺物料等）的建設(shè)以及前端行業(yè)領(lǐng)域的細(xì)分。
階段七：領(lǐng)域細(xì)分 & 可視化搭建
小前臺
面向的是消費(fèi)者端的 Web 與 輕 App 業(yè)務(wù)場景，在這個場景下，經(jīng)歷過多年?duì)I銷活動的沉淀，面向運(yùn)營、商家或 KOL 的頁面的可視化搭建系統(tǒng)也非常成熟。所以營銷活動基本靠這樣的系統(tǒng)支撐。
中后臺
數(shù)據(jù)可視化
互動內(nèi)容
AR、VR、3D、網(wǎng)游、短視頻、直播（WebRTC）等新技術(shù)在 web 上的衍生和普及，更多富導(dǎo)購的交互形式層出不窮，所以這個方向就是在面向未來的用戶富交互體驗(yàn)做投資建設(shè)。
……
還有更多的垂直領(lǐng)域，在此不再細(xì)說。
回看這 10 年，是互聯(lián)網(wǎng)發(fā)展和終端發(fā)展最快的 10 年，也是前端發(fā)展最快的 10 年，更是前端程序員掉頭發(fā)、白頭發(fā)最快的 10 年。因?yàn)闆]有哪個技術(shù)領(lǐng)域，可以層出不窮地出現(xiàn)新輪子、可以反復(fù)不斷的推翻升級升級推翻，但慶幸的是，經(jīng)歷過百家爭鳴之后的前端行業(yè)在各個領(lǐng)域內(nèi)的建設(shè)深度也愈發(fā)地趨漸成熟。與此同時，大家也會發(fā)現(xiàn)，這些復(fù)雜的建設(shè)也都是圍繞著能解決業(yè)務(wù)問題和能提升自身生產(chǎn)效率的角度出發(fā)的。
解決業(yè)務(wù)問題不說，那么前端為什么要關(guān)注生產(chǎn)效率問題呢？
因?yàn)檫@直接與阿里的業(yè)務(wù)體量相關(guān)，阿里每一年的業(yè)務(wù)體量都是相比去年翻番的（比如出海、下沉、創(chuàng)新業(yè)務(wù)……），所以如果生產(chǎn)力效率跟不上業(yè)務(wù)的發(fā)展節(jié)奏，那么在市場競爭上就不占優(yōu)勢，以 2019 年三四線下沉市場高度競對的場景為例，如果前端撐不住業(yè)務(wù)發(fā)展的節(jié)奏，還是慢慢悠悠地搞生產(chǎn)，那么企業(yè)就很難占據(jù)市場了。
所以，每個前端身上背負(fù)的都是業(yè)務(wù)體量的成倍增加，如何能快速支撐住業(yè)務(wù)發(fā)展以及如何幫助業(yè)務(wù)突圍和增長（2017 年手機(jī)出貨量觸頂下滑，移動端的自然用戶增長紅利達(dá)到頂峰，可以從《用戶流量紅利消退的下半場，淘寶如何保持高速增長？》（https://blog.csdn.net/Taobaojishu/article/details/101488512）便可感知到）是我們每時每刻都在思考的問題。
前端已到瓶頸！
我們知道，即便工程化能力已經(jīng)成熟，但還是解決不了的問題就是“生產(chǎn)效率”的問題，試想：
假設(shè) 1 個中等水平的前端產(chǎn)出一張功能齊全的頁面需要 1 周時間，1 個牛逼的前端可能只需 2 天時間；而即便都雇傭牛逼的前端，1 個前端單打獨(dú)斗一周之內(nèi)最多也就 4 張頁面產(chǎn)出，如果僅是生產(chǎn) 10 張頁面，那么雇傭 1~2 個牛逼的前端一周之內(nèi)就搞定了，但如果是生產(chǎn) 100 張、1000 張頁面呢？這個時候雇傭多少前端比較合適呢？高端人才的緊俏和招人成本的控制，都會導(dǎo)致廠內(nèi)的前端的業(yè)務(wù)壓力倍增。
解鈴還須系鈴人，所以業(yè)內(nèi)開始不斷地涌現(xiàn) hardcode 向 lowcode 方向轉(zhuǎn)變的提效熱潮。不說外界，單以阿里為例，面向中后臺、C 端、數(shù)據(jù)可視化方向的 lowcode 平臺就層出不窮，雖說上手復(fù)雜度很高（畢竟解決問題的復(fù)雜度擺在那里，就像 Photoshop 一樣），但也都在趨于成熟。
可這樣就高枕無憂了嘛？其實(shí)并沒有，因?yàn)闃I(yè)務(wù)的迭代速度太快了，即便有這些平臺存在了，依然還是解決不了業(yè)務(wù)上的燃眉之急、前端效率問題依然是業(yè)內(nèi)的瓶頸。
以我?guī)У膱F(tuán)隊(duì)為例，我們服務(wù)的每一條線下的業(yè)務(wù)量和復(fù)雜度都是居高不下（每條線承接的是千萬級流量，所以業(yè)務(wù)復(fù)雜度自然會高），除了日常產(chǎn)品迭代，每月至少有 1~2 次的營銷活動同時進(jìn)行，即便用了上述的 lowcode 產(chǎn)品，但還是解不了業(yè)務(wù)方頻繁上訴要人的困局，甚至排期、砍需求這種傳統(tǒng)小伎倆如今也對業(yè)務(wù)方?jīng)]有藥效了。
怎么辦？一人難敵四手，更何況是一堆數(shù)都數(shù)不過來的手了。
前端如何突圍？
要講清楚這一塊，我們換個視角看看。眾所周知，市場是有清濁、淘汰機(jī)制的，任何一個行業(yè)都不是一成不變的，只要有先進(jìn)的出現(xiàn)，那么就勢必會將落伍的清理淘汰掉，而這個過程自變量僅是時間。
就像電商互聯(lián)網(wǎng)興起的那一刻，有多少實(shí)體從業(yè)者會意識到自己的飯碗會跟不上時代？就像移動端來臨的那一刻，有多少公司及個人還在沉淫在 PC 的時代產(chǎn)物上，再后知后覺地意識到落后時已經(jīng)被競爭者甩了好幾條街了。
就像當(dāng) iOS、Android App 生態(tài)剛開始興起階段，不斷地有客戶端的人才在向市場輸入，而今當(dāng) App 在市場飽和、用戶分配在終端上安裝的 App 數(shù)量有限，以及移動端 Web 和輕 App 技術(shù)的飛速發(fā)展等客觀因素沖擊下，客戶端的從業(yè)者發(fā)現(xiàn)保住自己的飯碗越發(fā)的困難了。
就像 AI、區(qū)塊鏈興起，有一大批的算法從業(yè)者和新技術(shù)的創(chuàng)業(yè)公司輸出到市場，而經(jīng)過市場競爭的洗滌下，又發(fā)現(xiàn)算法人才飽和過剩、創(chuàng)業(yè)公司也死了一大片。
所以要看一個行業(yè)的未來發(fā)展怎樣，就看這個行業(yè)的人才目前和未來在市場上被密集需要的地方在哪、規(guī)則最混濁或混亂的地方在哪。如果說這個行業(yè)的規(guī)則出奇地清晰、人才的供給又出奇的冷靜，那么基本上來說，這個行業(yè)在市場的發(fā)展已經(jīng)達(dá)到平衡狀態(tài)，而能打破這種平衡重新建立平衡的也肯定是另外的行業(yè)的發(fā)展?jié)B入。
所以回歸到我們所處的前端行業(yè)，如今前端人才被需要的肯定是在互聯(lián)網(wǎng)公司，尤其是大廠，因?yàn)闃I(yè)務(wù)發(fā)展需要，且被需要的很密集（勞動密集型產(chǎn)業(yè)），而且這個行業(yè)恰巧也是發(fā)展規(guī)則相對混亂的。為何混亂呢？一方面是因終端多元化趨勢嚴(yán)重，比如智能穿戴設(shè)備和 IOT 智能家居、智慧醫(yī)療、智能建筑等新興產(chǎn)業(yè)的市場沖擊，另一方面是因業(yè)務(wù)的發(fā)展形態(tài)、發(fā)展規(guī)模、發(fā)展距離（國內(nèi)到國外）等因素的影響，都導(dǎo)致著過去的終端的技術(shù)規(guī)則無法適應(yīng)到新興終端領(lǐng)域內(nèi)，所以規(guī)則在變、技術(shù)在變、框架在變、從業(yè)者的領(lǐng)域也在變。
所以從這個角度看前端的職能領(lǐng)域只會越來越寬，人才的需求量只會越來越大，供給的能力要求只會越來越高?？梢哉f這是市場對前端這個行業(yè)利好的信號，但同樣也是對前端這個行業(yè)壓力提醒的信號，如果在這個市場內(nèi)的前端不能很好的解決市場壓力問題，一旦有新興技術(shù)手段形成的新生產(chǎn)力出現(xiàn)，那么前端的這個香餑餑的行業(yè)飯碗也就不保了。市場就是這樣冷靜殘酷的，當(dāng)市場出清淘汰一個行業(yè)的時候或許連一聲招呼都不會打，沒有為什么，這是發(fā)展的必須。
如今我們看清形勢，再反觀我們的生產(chǎn)力手段，可以說還是人肉勞動密集型的，就算招再牛逼的人才進(jìn)來，如還是以這種的生產(chǎn)手段生產(chǎn)，那么早晚都會被淘汰，不管有多資深，哪怕是專家、研究員。所以前端發(fā)展到這個檔口下，看似成熟，實(shí)則危機(jī)四伏。
我們需要反思，更需要一種全景視角的突破和自我革命。與其讓別人革我們的命，那么真不如我們自己革自己命。所以接下來前端的發(fā)展勢必會面臨著一個最習(xí)以為常卻又最為關(guān)鍵的挑戰(zhàn) —— 前端生產(chǎn)效率該如何翻倍的提升？
歷史的經(jīng)驗(yàn)告訴我們，一個行業(yè)的生產(chǎn)供給能力翻倍，那么一定跟這個行業(yè)的工藝手段脫不了關(guān)系。比如傳統(tǒng)制造業(yè)制造一款鞋子、織一塊布，都是人手工的，當(dāng)這種供給達(dá)到瓶頸之后，就開始出現(xiàn)機(jī)械化來輔助人來生產(chǎn)，機(jī)械化達(dá)到一定程度就是自動化，自動化就可以完全脫離人工進(jìn)行生產(chǎn)。
同樣的道理，前端目前的生產(chǎn)工藝還是人肉的，即便有一定的程度的 lowcode 產(chǎn)品手段來輔助前端釋放生產(chǎn)壓力，但還是解決不了供不應(yīng)求的問題，所以沒有別的辦法，只有一條路就是去人肉，改成完全自動化的生產(chǎn)手段，只有讓供給能力遠(yuǎn)遠(yuǎn)超越需求的市場增長指數(shù)，那么才能徹底解決供不應(yīng)求的問題。
那么，前端該如何將生產(chǎn)手段提升到自動化階段呢？
首先，我們能想到的生產(chǎn)手段上肯定不能重度依賴人，那么剩下的也僅有機(jī)器，對于我們而言，肯定就是計算機(jī)了。
其次，我們要想的問題是該如何用計算機(jī)來解決我們所面臨的生產(chǎn)問題，想到第一步不難，而最難的恰巧就是這一步。該怎么解呢（how）？
調(diào)研發(fā)現(xiàn)，市面上就 2 種形態(tài)的解決思路，一種就是堆人的 hardcode 方式，包括傳統(tǒng)的組件化生態(tài)，也都停留在這個階段上；再有一種解法是 lowcode 的方式，或者輔助自己或者輔助其他角色來做生產(chǎn)（換一句話來說就是生產(chǎn)關(guān)系轉(zhuǎn)移到其他角色身上），這種方式在特定領(lǐng)域內(nèi)能一定程度上提效，但一旦領(lǐng)域拓寬或稍有移植，就會面臨著不適應(yīng)，用它工作量反而比 hardcode 增加很多。目前我們就在第 2 階段，但生產(chǎn)效率問題還是非常突出。所以我選擇的解法是 nocode，雖然這個詞也不是我新創(chuàng)的，但這個詞的涵義足以表達(dá)我對生產(chǎn)力供給能力提升下一個階段的看法。而能幫助前端實(shí)現(xiàn) nocode 解法的技術(shù)，一定就是 AI（準(zhǔn)確來說是機(jī)器學(xué)習(xí)）。Why？
互聯(lián)網(wǎng)的發(fā)展就是帶來了海量的數(shù)據(jù)，依靠人腦已經(jīng)無法去分析清楚一個行業(yè)的特征了，至少我們都是凡人大眾，那種類似愛因斯坦的天才畢竟還是少見，不可能哪個行業(yè)都要等著愛因斯坦出現(xiàn)才能找到解決方案。所以凡人大腦做不到的事情我們就交給計算機(jī)來做，如今的 云計算發(fā)展和 AI 發(fā)展，已經(jīng)降低了我們應(yīng)用 AI 來解決我們問題的門檻，所以入行 AI 也是遲早的事，不可能每天都蒙著眼睛裝看不到，而且也一定程度上得承認(rèn) AI 比我們更聰明，所以逃避不了的事實(shí)我們干脆一些接受好了。AI 就是為海量數(shù)據(jù)和復(fù)雜問題而生的。
思維方式轉(zhuǎn)變
那么前端究竟該怎樣加持 AI 的能力呢？
這個問題對純前端從業(yè)者來說很難，對算法從業(yè)者來說也很難，但對既懂前端又會算法的從業(yè)者來說就不難了。為了講清楚這個問題，那么我首先來講解下這兩者解題思維的慣性差異是什么，幫助大家先從思想上進(jìn)行轉(zhuǎn)變，這樣大家也就更易接受一些。
我們以一個具體的案例為例：當(dāng)你的產(chǎn)品經(jīng)理讓你做一款類似下圖這樣過障的小游戲，管道洞口高度固定，且是勻速向左移動的，小鳥只會上下，同時受重力影響會跳動，你如何讓這只小鳥自己會躲避障礙成功過關(guān)呢？
demo 地址：https://xviniette.github.io/FlappyLearning/
重新審視求解
前端，里面的關(guān)鍵字是“端”，所謂的“前”就是交代離用戶最近的地方。所以用戶接觸到的終端（包括各種異形屏的、沒屏幕的僅有傳感器的終端等等）上面所呈現(xiàn)的任何人機(jī)交互內(nèi)容（可視覺傳達(dá)、聽覺傳達(dá)、肢體傳達(dá)、甚至可能嗅覺傳達(dá)等等）都可以認(rèn)為是前端職責(zé)范圍內(nèi)的工作。面對這種形式多樣的終端，要想快速產(chǎn)出人機(jī)交互的內(nèi)容，我們用 AI 該怎么做呢？
鑒于話題有點(diǎn)大，我們還是聚焦在 Web 頁面上（其他的以此類推），如何借助 AI 實(shí)現(xiàn)高效地生產(chǎn)呢？
一種思路是，首先，聚焦在網(wǎng)頁上能呈現(xiàn)的內(nèi)容形態(tài)看看到底有哪幾種（空間軸上的語言），比如文字、圖片、視頻（視頻可以理解為圖片的逐幀動畫，加上音頻）、音頻；然后，我們再看下網(wǎng)頁上什么樣的內(nèi)容是經(jīng)常變化的（時間軸上無序狀態(tài)），什么樣的內(nèi)容是通過交互方式產(chǎn)生變化的（時間軸上的有序狀態(tài)）。最后，我們的生產(chǎn)策略是，優(yōu)先考慮將一組時間軸上的訓(xùn)練數(shù)據(jù)喂給一個模型讓它識別出時間軸上的變化內(nèi)容，然后再借助 CV 或 NLP 模型針對變化的內(nèi)容進(jìn)行實(shí)體識別（實(shí)體識別可能具體到一系列的模型存在，比如細(xì)化到商品圖識別模型），再然后借助另外的 CV 或 NLP 模型來識別時間軸上不變的內(nèi)容（往往這部分內(nèi)容就是頁面布局和容器框架），再通過一系列實(shí)體識別模型來做頁面結(jié)構(gòu)代碼上的映射（高維空間向量余弦值相等）。理論上來說，如有大量的訓(xùn)練樣本數(shù)據(jù)，那么模型針對時間軸上的有序狀態(tài)（即事件響應(yīng)）也是可以慢慢自己學(xué)習(xí)出規(guī)律出來的。
上面這種思路是純算法的思路，其中沒有借助前端的任何思維模式來影響，但具體效果怎樣和實(shí)施難度上有多大呢，目前還不好說，至少我們自己也還沒開始這種嘗試。
也許上面思維未來是對的，但今天來說，前端還沒有準(zhǔn)備好，還在一步步進(jìn)行思維上的轉(zhuǎn)變和迭代，這的確是需要一個過程。而且機(jī)器學(xué)習(xí)也不是萬能的，它受模型的制約因素很大，而模型往往也是一種算力的象征。我們可以把機(jī)器學(xué)習(xí)比作是一個擁有高復(fù)雜度并行密集計算能力（高維空間上的矩陣計算）的統(tǒng)計學(xué)計算器，而模型就是這款計算器的內(nèi)核。也許它能在背后計算出
智能化的10年
2~3 年內(nèi)，前端智能化從業(yè)者數(shù)量翻倍，AI 在前端領(lǐng)域內(nèi)或多或少有一些產(chǎn)品形態(tài)上的應(yīng)用，終端開始浮現(xiàn)各種前端機(jī)器學(xué)習(xí)框架，用戶產(chǎn)品在智能化體驗(yàn)方面的設(shè)計也有對應(yīng)的傾斜，社區(qū)上也開始浮現(xiàn)出各種前端智能化的工程框架、訓(xùn)練框架和 AI 平臺；
3~5 年內(nèi)，前端智能化從業(yè)者數(shù)量繼續(xù)增長，傳統(tǒng)前端已經(jīng)被淘汰，前端領(lǐng)域內(nèi)智能化在特定領(lǐng)域內(nèi)小有成績，可以解決特定領(lǐng)域內(nèi)的一些業(yè)務(wù)或人力生產(chǎn)效率問題，終端智能體驗(yàn)會趨漸成熟，給用戶帶來的沉浸式體驗(yàn)增強(qiáng)，線上線下無屏化無差異體驗(yàn)趨近相同，社區(qū)上開始開源一些前端的智能化產(chǎn)品；
5~10年內(nèi)，前端智能化從業(yè)市場已趨近飽和，端智能體驗(yàn)設(shè)計者應(yīng)該在市場上比較吃香（如沉浸式人機(jī)對抗游戲等），nocode 問題應(yīng)該能徹底解決，但同時帶來其他的消費(fèi)訴求，可能會引入新的領(lǐng)域難題。
如今危機(jī)四伏，未來無限可期，所以大家還是要未雨綢繆，提前做好準(zhǔn)備。如今前端智能化是新賽道，如果想直接參加前端智能化第一線的，也可以通過下面這種方式加入我們。
團(tuán)隊(duì)產(chǎn)品
imgcook —— 由設(shè)計稿一鍵智能生成代碼（https://www.imgcook.com/）
pipcook —— 前端算法工程框架，前端應(yīng)用機(jī)器學(xué)習(xí)的最后一公里（https://github.com/alibaba/pipcook）
