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