原文出處：李靖（@Barret李靖）

Web 發(fā)展了幾十個春秋身隐，風起云涌，千變萬化买窟。我很慶幸自己沒有完整地經(jīng)歷過這些年頭丰泊，而是站在前人的肩膀上行走。Web 技術發(fā)展的速度讓人感覺那幾乎不是繼承式的迭代始绍，而是一次又一次的變革瞳购，一次又一次的創(chuàng)造。這幾年的前端亏推，更為之甚学赛！

我從 12 年底開始接觸前端年堆，12 年之前的前端發(fā)展情況只能從上一輩的筆觸中領會。本文會盤點從 09 年開始到 15 年間前端技術的革新罢屈，同時也會從多個角度，解讀近幾年前端技術發(fā)展的潛在因素篇亭，其中穿插了若干對前端演進的拙見缠捌，難免會有錯誤和疏漏，忘讀者可以補充和斧正译蒂。

那些年曼月，一度追捧，一度放棄

下面柔昼，花一些篇幅簡單回顧下 09 年到 15 年前端的發(fā)展歷程哑芹。

09 年，基礎類庫完善捕透，尋求突破

09 年之前聪姿，JavaScript 還處于對自身語言的完善過程中，而到了 09 年乙嘀，JavaScript 類庫已經(jīng)頗為成熟末购，jQuery/Prototype/Script.aculo.us/Dojo 等都已經(jīng)發(fā)布了好幾個 stable 版本，各大類庫也是相互吸收優(yōu)點虎谢，不斷完善并提高自身性能盟榴，然而功能上已經(jīng)沒有太多增加的勢頭。部分框架開始了思想上的轉變婴噩，更加注重前端開發(fā)的組織和結構擎场，條理性強了很多，如 YUI几莽，Dojo 等迅办。

從 ECMAScript 規(guī)范的爭執(zhí)，開啟了瀏覽器引擎大戰(zhàn)章蚣，各大廠商也趁機瓜分 IE6 份額礼饱，Chrome 和 Firefox 在這場戰(zhàn)役中取得小勝，V8 也敲響了前端的大門究驴。為了迎合市場的激烈競爭镊绪，IE 開始了升級之旅，09 年初發(fā)布 IE8洒忧，全面兼容 CSS2.1蝴韭。

而此時，Node.js 和 3G Mobile 這兩只巨獸開始浮出水面熙侍，Web 標準也開始向 HTML5榄鉴、ECMAScript5.0 靠攏履磨。

10 年，Web2.0 深入人心庆尘，開始性能挑戰(zhàn)

毫無疑問剃诅，這一年，各大巨頭都看清了 HTML5 是 web 發(fā)展的未來驶忌，在保留原來前端技術的狀態(tài)下矛辕，都簇擁著拉扯 HTML5 的裙擺。富客戶端應用也在這一年蓬勃生長付魔，ExtJS/Dojo 搖身變?yōu)槠髽I(yè)級框架聊品，各類組件化概念和產(chǎn)品如約而至。

延續(xù)著 09 年的變化几苍，10 年的前端顯得頗為沉寂翻屈，然而在標準的運用和推動上，各大廠商也是十分賣力妻坝。IE 9 出來了預覽第三版伸眶，iPhone 的 Safari 已經(jīng)能夠支持眾多 HTML5 內容：Canvas/Video/Audio/Geolocation/Storage/Application Cache/Web SQL Database 等。

W3C 宣布成立 Web 性能工作組刽宪，Google 和 Mozilla 紛紛推出應用商店赚抡，瀏覽器調試工具也豐富了起來，人們開始更多地關注開發(fā)體驗和性能問題纠屋。

11 年涂臣，HTML5 抗大旗，F(xiàn)lash 堪憂

2011 年 HTML5 的技術發(fā)展和推廣都向前邁進了一大步售担，語義明確的標簽體系赁遗、簡潔明了的富媒體支持、本地數(shù)據(jù)的儲存技術族铆、canvas 等等各類技術被廣泛應用岩四。這一年，很多 web 開發(fā)者也面臨一項技術的抉擇哥攘，HTML5 or Flash剖煌？從 Flash Player 11.1 開始，Adobe 不再繼續(xù)開發(fā)面向移動設備瀏覽器的 Flash 插件逝淹，積極投身于 HTML5耕姊，這意味著 Flash 技術的凋零。

這一年栅葡，HTML5 游戲火爆到了一個高潮茉兰，他的低門檻和高收益讓很多開發(fā)者眼紅，正因如此欣簇，移動端開發(fā)工具和調試工具也日益成熟规脸。jQuery 已經(jīng)成為大小公司日常開發(fā)的標配坯约，成千上萬的 JQ 插件讓網(wǎng)頁開發(fā)變得尤為輕松，而隨之而來的也是頁面的臃腫和性能調優(yōu)的深入探索莫鸭。

Node.js 已經(jīng)悄然崛起闹丐，在 github 上的訪問量已經(jīng)超過了 Rails，國內的云應用開始嘗試使用 Node.js被因，Node.js 相關工具也紛紛出來卿拴。

12 年，響應式開發(fā)氏身，工程化推進

隨著硬件技術的發(fā)展巍棱，各手機廠商又開始騷動起來惑畴，為了占有更多的市場蛋欣，不斷提高產(chǎn)品的性價比，體驗也得到了不斷的優(yōu)化如贷。借著先前兩年 HTML5 刮起的東風陷虎，移動端上的 web 開發(fā)也顫抖了起來。移動端的開發(fā)挑戰(zhàn)不亞于 PC 上對多個瀏覽器的支持杠袱，這一年尚猿，萌生了眾多移動端框架，如 Sencha Touch/Zepto.js/JQ Mobile 等楣富，相對 PC 端框架凿掂，它們更加輕便。

而移動端的崛起纹蝴，帶來了許多終端開發(fā)難題：多終端適配庄萎，多分辨率適配，遠程調試等等塘安，而隨著這些難題一個個被解決糠涛，移動端生長的勢頭變得更加強盛。此時 Twitter 也推出了 Bootstrap兼犯， 這個前端開發(fā)工具包不僅方便了前端忍捡，也方便了后端同學，它的出現(xiàn)讓快速建站更加簡單切黔。

編程思想的切換砸脊，迎來了 CoffeeScript 和 TypeScript，這兩個預處理語言的出現(xiàn)又為 JavaScript 引來了不少其他方向轉型過來的開發(fā)者纬霞。JavaScript 的兄弟 Node.js脓规，也在命令行領域開拓了一片不小的疆域，甚至有動搖 Perl 和 Ruby 地位的趨勢险领。

在前端工程化上侨舆，幾個派系相互爭斗秒紧，產(chǎn)出了 AMD、CMD挨下、KMD 等規(guī)范熔恢，也衍生了 SeaJS、RequireJS 等模塊化工具臭笆。前端在這一年很有跳躍感叙淌。

13 年，爆發(fā)式增長愁铺，百花齊放

規(guī)范和標準上有不少產(chǎn)出鹰霍。Web Components 的出現(xiàn)給前端開發(fā)開辟了新思路；WebDriver 規(guī)范的出來推動了自動化測試的進程茵乱，ECMAScript 6 的規(guī)范草案落地茂洒，Webapp 工作小組在這一年也是相當活躍。

Chrome 瀏覽器在這一年也有了很大的突破瓶竭，開始支持 SPDY督勺，使用 Blink 取代 webkit 作為 Chromium 的新渲染引擎，Chrome DevTools 的調試體驗大幅度提升斤贰。這一年中智哀，Chrome 連同其他瀏覽器廠商快速推動了各項草案規(guī)范的實現(xiàn)。

語言能力上依舊在增強荧恍，并且從 JS 開始擴散到 CSS瓷叫，出現(xiàn)了 LESS、SASS 和 Stylus 等預處理語言送巡，Web 開發(fā)變得更加緊湊摹菠。

而在無線端，應用不再局限于 Webapp授艰，由于流暢度辨嗽、性能等方面不能滿足用戶體驗的需求，各大公司開始轉向 Native 方向的研究淮腾，進而出現(xiàn)了 Hybrid 和 PhoneGap 的繁榮糟需，它們?yōu)?JS 調用了提供更多的設備 API。

Node.js 大放異彩谷朝，很多公司在生產(chǎn)環(huán)境中使用 Node.js洲押，同時也出現(xiàn)了諸如 Express、Meteor 等小巧的快速搭建 Node.js Server 的應用框架圆凰。

各瀏覽器的調試也是種類繁多杈帐、功能豐富，PhantomJS 在自動化測試上開始取代 Selenium，出現(xiàn)了眾多的遠程調試方案和工具挑童。

前端工程化開始普及累铅，各公司開始推出自己的前端集成開發(fā)解決方案。

14 年站叼，移動端的崛起娃兽，HTML5 和 ES6 落地

HTML5 正式定稿，這意味著尽楔，web page 正式演變?yōu)?web application投储。ES6 華麗麗走進前端，走的很穩(wěn)重阔馋，它的 Module/Class 等特性已經(jīng)完全讓這們語言具備了開發(fā)大型應用的能力玛荞。

大而厚的基礎庫難以滿足靈活場景，Mobile 要求極致體驗呕寝，MV* 庫鋪卷而來勋眯，如 avalon/angular/knockout 等。

Web Components 跨終端組件快速發(fā)展壁涎，移動端開發(fā)迎來一次升華凡恍。Node.js 前后端分離的流行志秃，中間層的出現(xiàn)改變了前后端的合作模式怔球。

2014 是顛覆式的一年，前端發(fā)展在這一年開始形成了一個短暫的穩(wěn)定格局浮还。

15 年竟坛，觀念的轉變，步入前端工業(yè)化生產(chǎn)

今年格外引人注目的框架是钧舌，類 React担汤。Facebook 在 React.js Conf 2015 大會上推出了基于 JavaScript 的開源框架 React Native，它結合了 Web 應用和 Native 應用的優(yōu)勢洼冻，可以使用 JavaScript 來開發(fā) iOS 和 Android 原生應用。在 JavaScript 中用 React 抽象操作系統(tǒng)原生的 UI 組件，代替 DOM 元素來渲染等序愚。敲一次代碼蜻势，能夠運行在多個平臺上，其優(yōu)勢可見一斑屋彪。除了 React 所宰，還有手機淘寶推出的 Weex 框架，它吸收了 vue.js 的編程精華畜挥，編程風格更加簡約仔粥。

在眾多構建工具中，如今瀟灑存活的并不多。體驗完 grunt 和 browserify 后躯泰，gulp 順勢而至谭羔，爾后又出現(xiàn)了 webpack、jspm 等麦向。而包管理工具口糕，經(jīng)歷了 components、bower磕蛇、spm 后景描，npm 開始主導整個市場。

Node.js 的應用已經(jīng)鋪天蓋地秀撇，各大公司前端都把 Node.js 作為分離前后端的主要手段超棺，并且在測試、監(jiān)控等方面沉淀了大量內容呵燕。不過棠绘，這個市場是很苛刻的，Node.js 的性能難以達到 C/C++ 的水平再扭，那么接下來要做的就是要提升性能氧苍，至少得接近 C/C++。

Web 規(guī)范和標準

最開始泛范，我們看到的 JavaScript 還只是一個簡單的腳本語言让虐，配合著 AJAX，在網(wǎng)頁上翻騰了好幾個年頭罢荡。隨著互聯(lián)網(wǎng)趨勢越來越明顯赡突，互聯(lián)網(wǎng)業(yè)務量和業(yè)務復雜度不斷增加，很多網(wǎng)頁變得相當復雜区赵，如讓我們震驚了好一會兒的 Gmail惭缰，交互復雜，體驗優(yōu)良笼才。為了更好的多人協(xié)作漱受，代碼中的 Utils 庫越來越大，在這些庫中骡送，基礎部分更多的是對 JavaScript 語言本身的拓展昂羡，比如給 String 加一個 repeat 函數(shù)，再加一個 trim 函數(shù)各谚，再加一個 endWith 函數(shù)等等紧憾。

復雜的業(yè)務中會經(jīng)常看到一層又一層的回調處理昌渤，回調的嵌套讓代碼的可讀性變的很差赴穗，而且很難將多個異步并行處理。為了改變這種編程范式，我們做了很多的思考般眉，使用事件監(jiān)聽了赵，使用各種手段拉直回調，平坦地調用甸赃。

慢慢的柿汛，如果你在關注 W3C 小組的動向，會發(fā)現(xiàn)埠对，那些被認可的络断，并且被廣泛重復定義的東西，都被納入了標準项玛。最開始的 jQuery/prototype貌笨，前者主要是對瀏覽器做兼容處理，讓開發(fā)者不再把精力放到瀏覽器的差異上襟沮；后者是對語言本身的拓展锥惋，對 JavaScript 各種類型做拓展，并且提供了一套拓展任何對象的功能集开伏。而現(xiàn)在的開發(fā)膀跌，我們很大程度上不再依托這些類庫。規(guī)范和標準已經(jīng)把這些差異都統(tǒng)一了固灵，String 中自帶了 includes/startsWith/endsWith/repeat/padStart/padEnd 等函數(shù)捅伤，Array 自帶了 from/forEach/of/keys/values/find/findIndex 函數(shù)…

規(guī)范的標準是為了讓開發(fā)者得到更好的編程體驗，編程不是目標怎虫，目標是將編程生產(chǎn)力轉化成實際效益暑认，越少的阻礙對開發(fā)者越有利困介。各瀏覽器廠商當然也認識到了這一點大审，他們不斷地提升自己產(chǎn)品的體驗，將標準中的新特性都融合進去座哩，比如 ES6 中的 Promise/Generator/Class/Module 等等徒扶。在這些內容普及之前，我們不需要加入 jQuery/prototype 這些「不純粹」的東西根穷，而是添加兩個 shim 和 polyfill姜骡，如 es5-shim，html5shiv 等等屿良。待到山花爛漫時圈澈，再輕松刪掉這些補丁程序。

這兩年工程化很熱尘惧，W3C 小組也看到了康栈，這就是市場的需求，為了完成一個大型應用的編程，就必須模塊化啥么、組件化登舞，于是在規(guī)范中也出現(xiàn)了 Module & Module Loader；Node.js 的到來悬荣，讓很多前端工程師開始接觸數(shù)據(jù)庫操作菠秒，面對巨量的異步，我們忍氣吞聲寫了無數(shù)的回調地獄氯迂，盡管使用了很多 Promise 相關的操作践叠，程序結構依然松散難以閱讀，于是規(guī)范中也開始出現(xiàn)了 async/await 等對 Generator 的上層封裝嚼蚀。文字已經(jīng)不能滿足當代人的溝通需求酵熙，音視頻等富媒體傳輸走進了我們的生活，于是規(guī)范中也出來了 WebRTC/WebAudio 等規(guī)范驰坊。

只要規(guī)范出來了匾二，后續(xù)市面上就會根據(jù)規(guī)范來實現(xiàn)一套 shiv，這些 shiv 提供了同樣的 API拳芙，提供了同樣的編程體驗察藐。當瀏覽器自我進化完成之后，這些 shiv 也將成為歷史舟扎，被開發(fā)者遺棄在代碼的注釋之中分飞。這些都是規(guī)范和標準的魅力，它的存在睹限，就是讓開發(fā)者把精力投入到自己的業(yè)務之中譬猫，編程和范式的工作交給它。

在這里可以看到羡疗，W3C 各個小組最近都在干啥染服。標準不能囊括一切。

生態(tài)的自我完善和自我拓展

技術的更迭過于頻繁叨恨，我們能夠清晰地看到柳刮，很多人還在用更迭前一波甚至是前好幾波的產(chǎn)品。

當年的 IE6痒钝，在戰(zhàn)場上鏖戰(zhàn)了 10 多個年頭秉颗，依然屹立不到，而現(xiàn)在它在市面上依然有百分之一左右的占有率送矩，這種小強精神不得不讓人肅然起敬蚕甥。“只要用戶在栋荸，我們就得追隨”菇怀，這可能是很多公司的服務理念夷家，因為用戶就是潛在的利潤。正是因為這種服務理念敏释，成就了 IE6 一個又一個的 5 年库快！然而低本版的 IE 已經(jīng)不僅僅是被前端從業(yè)人員抵制和排斥了，網(wǎng)絡安全钥顽、網(wǎng)絡運維义屏、QA 等等，各個技術崗位的人員都開始對他不屑蜂大，它的存在對工作效率闽铐、對安全、對很多方面產(chǎn)生了極為不良的影響奶浦，甚至影響到一些核心內容的推廣兄墅，所以 2016 將是低版本 IE 消亡的一年，我也呼吁業(yè)界所有的朋友舉起義旗反抗起來澳叉！

慶幸的是隙咸，也有人開始吃螃蟹了。從支付寶到天貓到淘寶成洗，阿里巴巴在很多業(yè)務上已經(jīng)主（bei）動（bi）地放棄了對 IE6 和 IE7 的支持五督，甚至在統(tǒng)一接入層直接做了 302 跳轉，提示用戶更新瀏覽器或者引導流量到無線端瓶殃。這是一個好的開始充包，我們期望這也是業(yè)界達成共識的開始！

HTTP 協(xié)議遥椿，從 1.0 快速過度到了 1.1基矮，整個互聯(lián)網(wǎng)的上層建筑變的十分穩(wěn)固。當然冠场，我也了解到依然有很多產(chǎn)品還是保持了 1.0 的狀態(tài)家浇，據(jù)說電信公司的很多產(chǎn)品就是使用 HTTP/1.0 進行通訊，這無疑讓人驚愕慈鸠。為了追求更高的效率蓝谨，減少網(wǎng)絡傳輸中的無效流量，W3C 工作組對 HTTP 協(xié)議也做了重新的定義青团，SPDY 就是 13 年比較火熱的一個話題，F(xiàn)irefox 和 Chrome 都陸續(xù)開始支持 SPDY咖楣，后來在 SPDY 的基礎上做了升級督笆，正式定義為 HTTP/2.0，它的一個很大特點就是多路復用诱贿，這個小小的特點改變了我們前端編程的很多優(yōu)化模式娃肿，比如

域名不是越多越好咕缎，為了能夠充分利用瀏覽器的連接數(shù)，我們給 JS 和 CSS 開一個域名料扰，給 img 開好幾個域名凭豪，網(wǎng)頁打開的時候，恰到好處的利用瀏覽器的連接數(shù)上限限制晒杈。HTTP/2.0 的多路復用嫂伞，就是可以在一個 HTTP 請求中進行多個資源的傳輸，如果域名散列拯钻，反而不能利用這個特性

資源合并沒有任何優(yōu)勢帖努，以前的資源合并是為了減少請求數(shù)以節(jié)約建立 TCP 鏈接的網(wǎng)絡開銷和頭部傳輸?shù)牧髁块_銷，而在 HTTP/2.0 中粪般，一個 HTTP 請求上完全可以把所有的資源全部推送過來拼余，如果合并了資源，反而不能良好運用瀏覽器對資源的緩存亩歹。

當然匙监，除了多路復用，還有很多其他的優(yōu)化小作，比如傳輸?shù)臄?shù)據(jù)為二進制流舅柜，HEAD 頭會被壓縮處理，服務器可以向客戶端推送內容等致份。在這個技術水平指數(shù)式增長的年代础拨，我相信以后的革新不會比消滅 IE6 痛苦。

模塊加載上诡宗，經(jīng)過了各派系的爭論之后滔蝉，流傳下來幾個不錯的產(chǎn)品 SeaJS、RequireJS 等蝠引，那么那個模塊加載器將成為工具平臺中短暫的終點呢蛀柴？似乎這些都不是螃概。當我們按照規(guī)范中的方式進行模塊定義，按照規(guī)范中的方式加載定義的模塊時鸽疾，加載這個流程就顯得不那么重要了吊洼，因為這些事情最后都會變成 shiv/polyfill 的事情冒窍，最終會變成瀏覽器的固有屬性。

當一個東西在社區(qū)中被暴力追捧的時候款慨，會有很多衍生的產(chǎn)品出來谬莹，當這些衍生物根深蒂固時，可能又會出現(xiàn)一個更加原生更加符合開發(fā)習慣的東西出來笆凌。就像 jQuery士葫，我們?yōu)樗帉懙牟寮挥嬈鋽?shù)，而在工程化的需求沖擊下爪模，它卻顯得那么的弱不禁風荚藻，因為它關注的點和當前的發(fā)展態(tài)勢不太吻合，僅此而已共郭。

Mobile 的發(fā)展驅動著戰(zhàn)場的轉移

記得當年拿著 Nokia5230 學完了 HTML 和 JavaScript 的入門除嘹，那屏幕尺寸也就是三個手指的寬度，緊緊攥在手里看著頁面混排效果極差的網(wǎng)頁文檔岸蜗。

現(xiàn)如今璃岳，iPhone 都出到 6s 了，一個版本一個尺寸单芜，而且尺寸越來越大枚冗，還有各種寬高不一的 Android 機器赁温，種類繁多。以前的觸屏是電阻式股囊，只支持單點觸碰稚疹；而現(xiàn)在電容式的觸屏精度更高，還支持多指觸控怪嫌，這如絲般順滑的體驗在三四年前是完全體會不到的柳沙。曾經(jīng)手機開一個程序久了就會卡赂鲤，動不動還會自動重啟；而現(xiàn)在的手機開一堆程序找爱，完全無感知泡孩，這就是硬件發(fā)展前后的差異仑鸥。

手機已經(jīng)成為了人們生活中不可或缺的一部分，甚至成為了一些人身體的一部分薄料，淘寶今年雙十一的數(shù)據(jù)顯示泵琳，國內移動端的消費比例已經(jīng)遠遠超過了 PC 端获列，占比 68%。面對龐大的用戶迫悠，我們的技術是否做好了充足的準備巩梢，這里還得打一個問好。

PC 上那一套經(jīng)驗不是直接搬到移動端就可以使用了鞠抑，在移動端還需要解決更多的問題：

多分辨率問題搁拙，這里涉及到了響應式設計和前端響應式技術

不同網(wǎng)絡環(huán)境的網(wǎng)頁加載優(yōu)化問題，2g/3g/4g/wifi

手指交互帶來的一系列體驗問題

為了提升用戶體驗酪碘，將 Web Native 化 —— 類 React 技術帶來的一系列問題

遠程調試問題

移動安全問題等等

上面提到的問題很多已經(jīng)有了優(yōu)秀的解決方案盐茎，當然也有很多未提及的庭呜。WebApp 的性能、流暢度和穩(wěn)定性遠遠不如原生應用扶关，同時它也無法良好地運用設備提供的原生功能数冬，這些都是大家轉投 Native 的原因拐纱。

端的融合

不同分辨率的手機，不同物理尺寸的終端揍庄，為了保持良好的視覺體驗和用戶體驗东抹，我們不得不為每一個尺寸寫一份 Media Query 代碼缭黔，那么對應的，設計師也需要設計多套版式供前端使用别渔，這給設計師、前端和測試帶來了無盡的麻煩喇伯。為此艘刚，我們通過前端技術重塑屏幕截珍，重新定義像素尺寸箩朴，使用流式布局炸庞，通過百分比來響應不同的終端尺寸。這是端的融合查牌。

后續(xù)的 Mobile 的技術發(fā)展方向上纸颜，應該是相當明確的绎橘。很多公司都是三套人馬維護三端的程序，iOS涮较、Android 和 Web狂票，而這三端做的事情都是一樣的熙暴，一樣的界面怨咪，一樣的后端接口，一樣的交互方式唉匾。為了能夠快速響應業(yè)務的變更，我們不得不將三端合并為一端對待厂财，用一套程序編程成三端代碼璃饱，然后發(fā)布到三個平臺上肪康。這也是端的融合磷支。React 系列技術發(fā)展到此，絕對不是終點廓潜，它只是一個探路燈善榛，給我們照明了方向移盆。

技術需要為業(yè)務做保障，而好的技術是能夠及時響應業(yè)務的變化樱蛤，我們不可能投入大量的人力在 Web 的修補工作上昨凡，通過開發(fā)統(tǒng)一工具蚁署，屏蔽端和端之間的差異光戈，統(tǒng)一開發(fā)模式和開發(fā)體驗，這才是 Mobile 的未來晌杰。

當然筷弦，回到我們之前說的規(guī)范和標準，我們目前所做的「屏蔽差異」工作蜕乡，今后梗夸，也會有統(tǒng)一的標準來規(guī)范反症，目前手機廠商沒有這個共識，是因為還處于當年 Chrome憨降、Firefox 搶占 IE6 市場份額的階段。端的最終融合在于一個統(tǒng)一的標準士嚎，以及強有力的執(zhí)行莱衩。

棧的融合

我剛接觸前端的時候，還沒有聽說「全椂蒙梗」伪很，Web 技術棧往小里說奋单，包含了從前端設計览濒、交互贷笛、前端實現(xiàn)、網(wǎng)絡數(shù)據(jù)傳輸株扛、后端實現(xiàn)、后端運維和數(shù)據(jù)庫等幾個方面叔磷，能短時間內從無到有實現(xiàn)這么一套系統(tǒng)改基，并且能夠抗得住一定流量沖擊的人咖为，我們可以稱之為全棧工程師躁染。能夠有架構有條理地實現(xiàn)這套系統(tǒng)吞彤，并且抗得住大流量、有集成測試挠羔、有監(jiān)控的破加，這種我們可以稱之為資深全棧工程師”⑧拢現(xiàn)在不乏這種人才了罪，也不乏自吹為這種人。

棧的融合得益于 Node.js 的出現(xiàn)田藐，作為前后端分離的橋梁汽久，它拉近了前端工程師與后端的距離踊餐，有的人在這座橋梁上賣力行走吝岭，漸漸的也從前端走進 了后端，甚至走進了后端的運維散劫。至此获搏，前端也擁有了部署和發(fā)布整個應用的能力常熙，這是一個質的突破。

使用 Node.js仿贬，簡單幾行程序便能實現(xiàn)一個 web 服務器茧泪、便能搭建一個多人聊天的網(wǎng)頁调炬，它的便捷性可見一斑舱馅。NPM 社區(qū)的發(fā)展代嗤，沉淀了成千上萬的組件包缠借，一行命令即可獲取泼返，這種組件拼湊式的開發(fā)绅喉，任何功能的實現(xiàn)都不會顯得太復雜，而這里的「不復雜」也蘊含了無數(shù)的坑坑洼洼徽缚，在這一層的融合上也會遇上不少阻礙：

冗余的龐大的包內容凿试，為了使用一個小功能那婉，我們從網(wǎng)絡上拉取下來一個巨大的包，而且這里的「巨大」對很多人來說都是無感知的盐类，很少會有人進入 node_modules 去查看依賴的第三方包是如何實現(xiàn)的傲醉，實際情況可能會相當震撼硬毕，第三方包還引用了一堆第三方包礼仗，這些包都會在 Node.js 執(zhí)行的時候被收納進去元践，放在內存中单旁。

猛烈的迭代，今年的 Node.js 被人嫌棄迭代太慢了（當然蔫饰，這是表面原因）篓吁，走出了一個分支 io.js杖剪，發(fā)展了一會兒驰贷，進度趕超了 Node.js饱苟，后來覺得一家人不干兩家活箱熬，又合并回去了狈邑。雖說上層 API 幾乎沒有變化，但是底層卻被翻了一個天蚤认。

偶爾的巨大漏洞米苹，每隔一端時間就會暴露 Node.js 存在漏洞，這些漏洞的補救措施就是立即升級版本號砰琢，比較讓人擔心受怕蘸嘶。

后端意識不強烈，前端占領了中間層的開發(fā)陪汽，有的時候還干這后端的活兒训唱，然而卻沒有后端沉淀多年固有的意識，測試和監(jiān)控做的相當潦草况增。

JavaScript 從客戶端的腳本語言縱身躍進進入了后端行列，而今也開始深入到移動端 Native 領域训挡，確實是無孔不入澳骤，這可能就是語言的特性，也可能是技術本身就在尋求融合點澜薄，把有差異的地方全部躺平为肮，然后用統(tǒng)一的方式去關注業(yè)務，關注用戶肤京。端和棧也在融合颊艳。

后端服務化，云數(shù)據(jù)忘分，云安全

用戶體驗變得越來越重要籽暇，響應式技術的發(fā)展也是后續(xù)網(wǎng)頁應用的一大特點，端和端之間的差異只是在表現(xiàn)上饭庞，數(shù)據(jù)這一層差異不是特別打，很多應用 PC 和 Mobile 共用一套接口熬荆，或者 Mobile 的接口在 PC 接口的基礎上做了一層包裝舟山，對接口字段做了些許刪減。后端為了響應各個端之間的數(shù)據(jù)需求卤恳，也需要關注數(shù)據(jù)的可利用性累盗，接口包裝的拓展性等，這是后端服務化的一個表現(xiàn)突琳。移動端的開發(fā)上若债，前后端間隙十分明顯，越來越多移動端應用的發(fā)布已經(jīng)脫離了后端拆融，前端完全通過異步方式獲取數(shù)據(jù)蠢琳。

業(yè)務變化很快很快快啊终，今天這個產(chǎn)品被并購，明天那個業(yè)務被砍掉傲须，每個人負責的業(yè)務線可能冷不丁地就變了蓝牲。很多大公司的決策是由上往下的，上面微動泰讽，下面可能就是大動例衍，可能某個部門就不存在了，也可能被劃分成幾個產(chǎn)品部門已卸。

所以「大后臺佛玄，小前臺」的趨勢必然形成。前端累澡，毫無疑問梦抢，在這個前臺之中。前臺的特點是靈活的永乌，多變的惑申，可快速重組的。對后臺而言翅雏，為了響應前臺的變化圈驼，需要提供更細粒化的 API望几，將數(shù)據(jù)打散绩脆，打得更加零碎，零碎的數(shù)據(jù)易于重組橄抹，這是在考驗后端的架構能力靴迫。如今，很多前端也都是半棧工程師楼誓，盤踞在前后端中間層上玉锌，然而如何迎接這種后端服務化的模式，似乎這個準備還是不夠充足的疟羹。

GraphQL 的出現(xiàn)場景跟 React 類似主守，React 是前端應對不同場景的一種強有力手段，而 GraphQL 則是后端應對不同需求場景的一次嘗試榄融，Web APIs 將會成為 Web App 和 Mobile App 的一個中心點参淫，前端基于后端的 RESTful 服務構建應用，這里面存在太多未知的問題需要探索愧杯，這是一個大數(shù)據(jù)下探索的新起點涎才，也給前端開發(fā)者創(chuàng)造了無數(shù)的可能。

這幾年各類網(wǎng)盤力九，各個云服務商都在搶占市場耍铜，有提供圖片儲存的邑闺，有提供 CDN 靜態(tài)資源緩存的，有提供大文件儲存的业扒，也有賣數(shù)據(jù)庫服務的检吆。種類繁多，而歸根到底都是程储，你付錢給我蹭沛，我提供儲存和安全，還提供方便的 SDK 讓你獲取自己的數(shù)據(jù)章鲤。云服務賣的是一套服務摊灭，它是把所有人的數(shù)據(jù)風險集于一身，用強硬的技術做安全防御败徊。云帚呼，賦予了我們無窮的想象空間。

三輛馬車皱蹦，我們還差一輛

開發(fā)功能對很多人來說是輕松活兒煤杀，基本的前端語言加些復雜的特效，實現(xiàn)成本不會很高沪哺；即便是搭建一個網(wǎng)站沈自，使用 Node.js 社區(qū)中的框架也能夠輕松實現(xiàn)。然后極少人會去關注每個功能點的測試辜妓，一個項目下來基本看不到測試用例枯途，更不用說會去做監(jiān)控相關的事情。結果就是籍滴，踏過了無數(shù)的坑洼之后終于上線了酪夷，而后續(xù)加功能的時候發(fā)現(xiàn)，加了東西就跑不通孽惰，新內容影響了之前的邏輯晚岭，只好去修復之前的邏輯，修好之后發(fā)現(xiàn)更早之前的邏輯又不通了勋功，整個修復過程就像玩多米諾骨牌腥例。

程序開發(fā)三板斧：功能、測試和監(jiān)控酝润。在 github 上可以看到很多程序都加入了持續(xù)集成，這是一個好兆頭璃弄，以為著我們寫的程序也越來越健壯要销，至少貢獻給世人使用的程序是健壯的。很多程序的代碼覆蓋率也達到了 90%+夏块，這些數(shù)據(jù)都是重視測試的證據(jù)疏咐。

然而纤掸，三輛馬車，我們最后一輛依然沒有開動起來浑塞。很多公司都會有自己的 log 平臺借跪，每個用戶訪問頁面中的任何一個鏈接都會將用戶信息和訪問信息以 log 日志形式收集到 log 平臺上，然后通過監(jiān)控平臺或者離線分析的方式酌壕，獲取業(yè)務數(shù)據(jù)或者技術數(shù)據(jù)掏愁，進行分析和二次開發(fā)。這些東西在大公司見的很多卵牍，而這方面的東西在前端果港，尤其是使用 Node.js 做程序開發(fā)的前端身上，看到的并不多糊昙。

最后

2016 年辛掠，我覺得技術上的新創(chuàng)造會稍微緩和些，這兩年很多人已經(jīng)被新技術沖擊得有些找不著方向了释牺，同一類東西萝衩，前者還沒學完，后者就開始火爆了没咙，緊接著又是一陣技術的凋零和新技術的出現(xiàn)猩谊，這樣搞久了也會有一絲的疲倦。而更多的會關注镜撩，如何更好地服務多端预柒，如何更大幅度地提升開發(fā)體驗和用戶體驗，很多技術都會往性能袁梗、往極致這個方向上鉆研宜鸯。

寫長文真不輕松。寫到這里遮怜，感覺說的不通透淋袖，還有很多想說的，但是個人理解力有限锯梁，也難以表達全面即碗。技術的變化很快，今天說過的東西陌凳，到了明天就可能過時了剥懒。我們猜不透未來，只能把現(xiàn)有的東西好好消化吸收下合敦，留下一個話柄初橘，給讀者吧。