原文：21 hot programming trends—and 21 going cold

鏈接：

譯者：Tocy, douxingxiang, 無(wú)若, leoxu, cassia_tora, chloe900, 翻譯狂, -_-struggle

不過(guò)這也并不是說(shuō)編程就是一個(gè)沒(méi)有趨勢(shì)走向的行業(yè)。不同之處就在于編程的趨勢(shì)是由更高的效率，越來(lái)越多的定制化以及更佳的易用性這些因素來(lái)驅(qū)動(dòng)的。

新一代的技術(shù)都是上代技術(shù)沉淀升級(jí)的結(jié)果。這是一種精益求精的過(guò)程，而非朝令夕改的奇思妙想。

如下是一份展示如今在程序員群體中比較熱門和冷門的技術(shù)趨勢(shì)清單。清單中所列不一定會(huì)得到所有人的認(rèn)同，也可能有遺漏的。這也就是為什么編程會(huì)是這樣一個(gè)無(wú)窮無(wú)盡的迷人領(lǐng)域: 快速的變化，激烈的爭(zhēng)論，還有突然的峰回路轉(zhuǎn)。

就在不久以前，人們?cè)趧?chuàng)造一種新的編程語(yǔ)言時(shí)還不得不構(gòu)造一個(gè)將代碼寫到硅片中的環(huán)境。然后有人指出他們可以提前把這項(xiàng)工作完成?，F(xiàn)在，機(jī)智的人們只需編寫一個(gè)預(yù)處理器（將最新的代碼轉(zhuǎn)換成一組具有豐富的庫(kù)和 API 的舊版本代碼）。

像 Python 或者 JavaScript 這種腳本語(yǔ)言一直囿于小項(xiàng)目，然而現(xiàn)在它們是很多大型項(xiàng)目的基礎(chǔ)。并且那些不喜歡 JavaScript 的家伙創(chuàng)造了 CoffeeScript，一個(gè)讓程序員編程時(shí)不用糾結(jié)那些復(fù)雜的標(biāo)點(diǎn)的預(yù)處理器。它有幾十種以不同的方式預(yù)測(cè)語(yǔ)法的變體。

這些喜歡動(dòng)態(tài)輸入的家伙創(chuàng)造了 Groovy，Groory 是一個(gè)沒(méi)有過(guò)于糾結(jié)標(biāo)點(diǎn)的 Java 簡(jiǎn)化版。還有很多類似 Scale 或 Clojure 的語(yǔ)言，這些語(yǔ)言運(yùn)行在 JVM 上，但是最多只能同時(shí)在一個(gè) JVM 上運(yùn)行。你可以在虛擬機(jī)上運(yùn)行很多種語(yǔ)言。為什么還要重復(fù)造輪子呢。

這并不完全正確。盡管 Docker 容器比虛擬機(jī)的鏡像文件小很多，制作它們也相對(duì)容易，也便于部署。但是 hypervisors 仍然有它的一席之地，很多 Docker 容器是運(yùn)行在操作系統(tǒng)內(nèi)部的，而那些操作系統(tǒng)又是運(yùn)行在 hypervisors 之上的。

當(dāng)開發(fā)人員可以使用 Docker 的時(shí)候，他們還是更傾向于使用 Docker 容器，這主要?dú)w功于 Docker 在部署過(guò)程中可以輕松地進(jìn)行操作。聰明的公司例如，Joyent 已經(jīng)在思考如何更多地?cái)D掉多余的“脂肪”，能讓容器在“裸機(jī)”上運(yùn)行。

在數(shù)字商業(yè)時(shí)代，你需要靈活地抓住新的機(jī)會(huì)，也要更有效地維護(hù)好留下的遺產(chǎn)和基礎(chǔ)系統(tǒng)。

很久以前，每個(gè)人都學(xué)習(xí)過(guò)用 JavaScript 來(lái)彈出一個(gè) alert 框體或者用它來(lái)檢查 email 地址中是否包含@符號(hào)?，F(xiàn)在， HTML AJAX 應(yīng)用已經(jīng)如此成熟，很少有人會(huì)從頭開始做這些工作了。簡(jiǎn)單地采用一個(gè)精心制作的框架，寫一些膠水代碼來(lái)實(shí)現(xiàn)一下你的業(yè)務(wù)邏輯就行了。

現(xiàn)在已經(jīng)有了眾多的框架，像 Kendo, Sencha, jQuery Mobile, AngularJS, Ember, Backbone, Meteor JS 等等，它們都是準(zhǔn)備用于處理你的 web 應(yīng)用和頁(yè)面上的內(nèi)容和事件的。

除了 web 應(yīng)用。還有大量的旨在為智能手機(jī)或者平板電腦等跨平臺(tái)開發(fā)準(zhǔn)備的框架、技術(shù)等，例如：NativeScript, PhoneGap, 和 Ext JS 都是創(chuàng)建 HTML5 應(yīng)用的選擇。

從前，向網(wǎng)頁(yè)添加新元素就意味著打開 CSS 文件并添加一個(gè)新的命令，如 font-style:italic，保存了這個(gè)文件后，就可以去吃午飯了。但是現(xiàn)在網(wǎng)頁(yè)變得異常復(fù)雜，再也無(wú)法用這樣簡(jiǎn)單的命令來(lái)填充文件。一個(gè)顏色調(diào)整可能會(huì)導(dǎo)致其他一切都出問(wèn)題。這就像他們對(duì)陰謀和生態(tài)的看法：一切都是相互關(guān)聯(lián)的。

就像 SASS 和它的近親 Compass 那樣的 CSS 框架已經(jīng)找到了堅(jiān)實(shí)的基礎(chǔ)。它們通過(guò)提供諸如實(shí)變量、嵌套塊和 mix-in 等編程結(jié)構(gòu)（如實(shí)變量，嵌套塊和混合）來(lái)鼓勵(lì)規(guī)范、可靠的編碼。 在程序?qū)又锌赡苈犉饋?lái)并不新鮮，但它對(duì)于設(shè)計(jì)層來(lái)說(shuō)卻是一個(gè)重大的飛躍。

曾經(jīng)有一段時(shí)間，視頻是你在 YouTube 或 Vimeo 上觀看過(guò)的內(nèi)容。這些都是保存在一個(gè)專門的頁(yè)面上獨(dú)立存在的。隨著越來(lái)越多的網(wǎng)站使用視頻作為靜態(tài) GIF 或 JPG 的構(gòu)建塊，這種趨勢(shì)正在發(fā)生變化。 突然之間，屏幕也開始隨著人們或者狗走動(dòng)而移動(dòng)起來(lái)。

設(shè)計(jì)人員發(fā)現(xiàn)，現(xiàn)代視頻標(biāo)簽只是另一個(gè)矩形，盡管這些矩形通常需要一些程序員的 JavaScript 代碼來(lái)控制它。我們開始明白，視頻并不是在客廳沙發(fā)前的機(jī)器盒子的主要內(nèi)容，而僅僅是一個(gè)裝飾。

每個(gè)人都喜歡自己是圈子的大人物，如果不是，那就找個(gè)大小合適的圈子，這樣就能脫穎而出了。所以當(dāng)“大數(shù)據(jù)”這個(gè)詞開始通過(guò)可執(zhí)行的程序套件流行起來(lái)的時(shí)候，買主們就開始嚷嚷著要最大，最強(qiáng)的大數(shù)據(jù)系統(tǒng)，說(shuō)得好像他們要掃的貨是游艇或者摩天大樓一樣。

有意思的是許多問(wèn)題都還不夠大，談不上要去使用最好的大數(shù)據(jù)解決方案來(lái)進(jìn)行處理。當(dāng)然，像 Google 或 Yahoo 這樣的公司，它們會(huì)跟蹤我們所有的網(wǎng)頁(yè)瀏覽行為，所以它們的數(shù)據(jù)文件要以兆字節(jié)或百兆字節(jié)為單位。而大多數(shù)公司所擁有的那些數(shù)據(jù)量使用基礎(chǔ)的 PC 的 RAM 就可輕松對(duì)付了。

我正在寫下這些內(nèi)容的時(shí)候，使用的是一臺(tái) 16GB 內(nèi)存的電腦——這樣的配置足夠處理數(shù)十億事件的那么點(diǎn)數(shù)據(jù)量了。在大多數(shù)算法中，數(shù)據(jù)并不需要從內(nèi)存讀入，因?yàn)閺?SSD 導(dǎo)入也是不錯(cuò)的選擇。

有些場(chǎng)景會(huì)要求在一個(gè) Hadoop 云中并行跑著的幾十臺(tái)機(jī)器在時(shí)間上能夠快速響應(yīng)，但許多其它的場(chǎng)景下作為單臺(tái)機(jī)器上的一個(gè)可插拔的服務(wù)就可以了，也不會(huì)有啥協(xié)作和通信方面的問(wèn)題。

Hadoop 熱度并沒(méi)有冷卻多少。只是 Spark 變得更紅更熱，使得 Hadoop 模型看起來(lái)有點(diǎn)老了罷了。Spark 借鑒了一些 Hadoop 從大量數(shù)據(jù)中提取語(yǔ)義方法的最優(yōu)策略，并通過(guò)一些可靠的改進(jìn)來(lái)更新它們，來(lái)使代碼運(yùn)行得更快。Spark 很可能會(huì)將數(shù)據(jù)保存在快速內(nèi)存中，而不是要求所有內(nèi)容必須寫入分布式文件系統(tǒng)中。

當(dāng)然，許多人通過(guò) Spark 快速處理數(shù)據(jù)并肩器存儲(chǔ)在 Hadoop 分布式文件系統(tǒng)的混合策略來(lái)使用二者。相比于競(jìng)爭(zhēng)對(duì)手，他們更像是合作伙伴。

自從“大數(shù)據(jù)”這個(gè)詞火了之后，還沒(méi)有多少人知道“人工智能”這個(gè)短語(yǔ)的意思，這可幫了銷售人員一個(gè)大忙。他們正從人工智能中獲得條件通過(guò)分析日志文件和點(diǎn)擊流獲得的數(shù)據(jù)處理算法升級(jí)“大數(shù)據(jù)”的復(fù)雜性。

從 50 余年的 AI 研究中，我們得到了大量復(fù)雜的算法，相比以前，我們更有機(jī)會(huì)找出信號(hào)的噪聲。從機(jī)器學(xué)習(xí)框架到認(rèn)知計(jì)算再到 IBM 的“Watson”，都有工具去解決你的問(wèn)題。每一種工具都提供了自己的只能水平，正是因?yàn)橛辛怂鼈儯覀儾拍茏龈嗟臄?shù)據(jù)分析和取證工作。

只需幾分鐘，我們就進(jìn)入了一個(gè)虛擬的世界：所有東西都是通過(guò)視頻卡直接投影到我們的視網(wǎng)膜上。這種場(chǎng)景一定會(huì)發(fā)生，但是就目前而言，機(jī)器人學(xué)正處于爆炸式的發(fā)展中。

每所高校都有機(jī)器人小組，而且各種機(jī)器正在闖入你你房子的每個(gè)角落。掃地機(jī)器人已經(jīng)是舊聞了，無(wú)人機(jī)已經(jīng)開始自由飛翔。

這意味著程序員需要開始思考如何編寫代碼來(lái)控制這些新機(jī)器。 從目前來(lái)看，這有點(diǎn)像為Raspberry Pi這樣的輕量級(jí)控件編寫腳本，但隨著函數(shù)庫(kù)的發(fā)展更加復(fù)雜，這一切都將會(huì)發(fā)生變化。

例如，就像許多機(jī)器人專家啃OpenCV（一個(gè)C語(yǔ)言的機(jī)器視覺平臺(tái)）中的代碼一樣。這意味著新的規(guī)則，新的函數(shù)庫(kù)，新的協(xié)議以及許多其他新的話題需要考慮。

曾記否，網(wǎng)址 URL 指向填滿靜態(tài)文字和圖片的網(wǎng)頁(yè)？ 將所有信息放在稱為網(wǎng)站的單獨(dú)頁(yè)面上是多么簡(jiǎn)單和精巧。設(shè)計(jì)團(tuán)隊(duì)將在網(wǎng)站地圖上花費(fèi)數(shù)小時(shí)的時(shí)間，并嘗試使其導(dǎo)航更加簡(jiǎn)單。

新的網(wǎng)絡(luò)應(yīng)用程序是存儲(chǔ)內(nèi)容的大型數(shù)據(jù)庫(kù)的前端。當(dāng)網(wǎng)絡(luò)應(yīng)用程序需要信息時(shí)，它將其從數(shù)據(jù)庫(kù)中提取出來(lái)并將其放置到本地端顯示。這里沒(méi)有必要使用構(gòu)建網(wǎng)頁(yè)所需的所有網(wǎng)絡(luò)組件來(lái)標(biāo)記數(shù)據(jù)。 數(shù)據(jù)層與呈現(xiàn)層和格式化層是完全分開的。

另一個(gè)移動(dòng)計(jì)算興起的因素是：一個(gè)單一的、響應(yīng)式設(shè)計(jì)的網(wǎng)頁(yè)可以像應(yīng)用程序一樣工作，以更好地避免 APP 商店的混亂。

假設(shè)您有一個(gè)移動(dòng)內(nèi)容方面的想法，你可以在 iOS、Android、Windows 8，甚至是 BlackBerry 操作系統(tǒng)或其他其他操作系統(tǒng)分開編寫單獨(dú)的版本。

但是每個(gè)版本都需要一個(gè)獨(dú)立的團(tuán)隊(duì)使用不同的編程語(yǔ)言編寫。然后，每個(gè)平臺(tái)的應(yīng)用程序商店都會(huì)發(fā)出自己的版本，然后才能將應(yīng)用程序發(fā)送給用戶。

又或者你可以構(gòu)建一個(gè) HTML 應(yīng)用程序，并將其放在網(wǎng)站上，這樣就可以在所有平臺(tái)上運(yùn)行。如果有變動(dòng)，不需要回到應(yīng)用商店即可請(qǐng)求快速審核錯(cuò)誤修復(fù)。

現(xiàn)在 HTML layer 發(fā)展越來(lái)越快，也在更快的芯片上運(yùn)行，讓其能在復(fù)雜性和互動(dòng)性更強(qiáng)的應(yīng)用程序上更好地與本地應(yīng)用程序進(jìn)行競(jìng)爭(zhēng)。

才過(guò)了幾年時(shí)間，焦點(diǎn)似乎就不再在蘋果的商店了？時(shí)代變化。雖然 iPhone 和 iPad 依然有一群喜愛他們精致的用戶界面的專業(yè)粉絲，但銷售數(shù)據(jù)更偏愛 Android。有報(bào)道甚至說(shuō)80％以上的手機(jī)都是Android。

原因可能就是成本這么簡(jiǎn)單。如果 iOS 設(shè)備花費(fèi)一分錢的話，Android 世界總會(huì)有大量的競(jìng)爭(zhēng)者來(lái)讓平板電腦的價(jià)格低至 iOS 的五分之一。省錢總是最大的誘惑力。

但另一個(gè)因素可能是開源。任何人都可以在市場(chǎng)上競(jìng)爭(zhēng)，現(xiàn)在亦如此。市場(chǎng)上有大尺寸的 Android 平板電腦和一些小尺寸的設(shè)備，也有 Android 相機(jī)甚至 Android 冰箱。沒(méi)有人會(huì)在將自己的創(chuàng)新想法付諸實(shí)踐之前問(wèn) Google，“媽媽，我可以嗎？”他們會(huì)馬上開干。

不過(guò)，蘋果正在向 Android 學(xué)習(xí)。iPhone 6 具有不同的屏幕尺寸，你知道嗎？焦點(diǎn)開始再次出現(xiàn)了。

當(dāng)軟件做地很簡(jiǎn)單，指令在一個(gè)流水線上運(yùn)行地很好的時(shí)候，CPU 就是整個(gè)電腦的老大，因?yàn)樗隽讼到y(tǒng)中最沉重的任務(wù)。

但是現(xiàn)在，視頻游戲中充斥著大量的并行圖形處理任務(wù)，這使得顯卡處理速度變得很慢。顯卡的價(jià)格很容易達(dá)到5、6百美元甚至更多，而且有些游戲發(fā)燒友使用1個(gè)以上的顯卡。

顯卡的價(jià)格達(dá)到了很多臺(tái)式機(jī)價(jià)格的兩倍以上。游戲玩家并不是唯一吹噓他們顯卡的人，計(jì)算機(jī)科學(xué)家現(xiàn)在正將很多并行程序放到 GPU 上運(yùn)行，使其運(yùn)算速度提升了上百倍。

當(dāng)然，你可以通過(guò)閱讀包括初級(jí)棋牌俱樂(lè)部副總裁的獲獎(jiǎng)名單來(lái)了解候選人。但閱讀某人編寫的代碼是一件更有趣和更有啟發(fā)性的事情。

他們寫好注釋了嗎？ 他們是否浪費(fèi)了大把時(shí)間把條目放進(jìn)小小的類中？這個(gè)架構(gòu)真的可擴(kuò)展嗎？ 所有這些問(wèn)題都可以通過(guò)他們的代碼看到。

這就是為什么參與開源項(xiàng)目在找工作的過(guò)程中變得越來(lái)越重要。共享私有項(xiàng)目的代碼幾乎是不可能的，但開源代碼能用在任何地方。

當(dāng)亞馬遜推出黑色星期五電腦和其他電子產(chǎn)品促銷活動(dòng)時(shí)，卻忘了炒作它的云產(chǎn)品。在不久前，各種公司都建設(shè)他們自己的數(shù)據(jù)中心，雇傭員工來(lái)管理他們購(gòu)買的設(shè)備。

但是現(xiàn)在，他們租用電腦、數(shù)據(jù)中心、員工、甚至按小時(shí)來(lái)租用軟件。沒(méi)有人想麻煩地?fù)碛懈鞣N東西。這是一個(gè)好主意，除非網(wǎng)上正散播著病毒或者你意識(shí)到一點(diǎn)擊就能買到任何東西，不再需要它的時(shí)候。

現(xiàn)在如果只有亞馬遜找到了一種自動(dòng)化提供云服務(wù)的方法，那么這個(gè)趨勢(shì)就會(huì)降低。

在云計(jì)算的初期，廠商強(qiáng)調(diào)的是，點(diǎn)擊一個(gè)按鈕就能把機(jī)器運(yùn)行起來(lái)。簡(jiǎn)單為王。

如今，更多的時(shí)間可能花在選擇合適的機(jī)器、合適的打折活動(dòng)上。機(jī)器配置很多，大多數(shù)云提供商都支持其中一些老式類型，并且提供完全不同的性能級(jí)別。所以最好提前進(jìn)行基準(zhǔn)測(cè)試來(lái)判斷哪個(gè)是最經(jīng)濟(jì)高效的選擇。

內(nèi)存少一點(diǎn)，但是每小時(shí)可以節(jié)省12美分的花費(fèi)是否值得？如果你同時(shí)有100臺(tái)機(jī)器要運(yùn)行數(shù)月，那可能是值得的。

更復(fù)雜的是，云廠商會(huì)對(duì)提前支付、打包購(gòu)買提供多種折扣方案。你也需要考慮到這些因素。花些錢在云花費(fèi)工程相關(guān)的在線課程上就能了解清楚了。

數(shù)據(jù)量小的時(shí)候，我們不用關(guān)心轉(zhuǎn)移的問(wèn)題。我們可以備份到磁帶，或者存放到 RAID 硬盤中。如今數(shù)據(jù)如此之大，以至于我們無(wú)法估計(jì)哪里能用到。

這個(gè)問(wèn)題變得愈加重要，因?yàn)樵絹?lái)越多的服務(wù)發(fā)生在云端，而不是 RAID 陣列所在的支架。

比如 Amazon 的新推出的 Snowmobile 裝運(yùn)容器，這是個(gè)有趣的內(nèi)部名字，容器內(nèi)裝滿硬盤，總計(jì)可以容納 100PB 數(shù)據(jù)。他們還有一個(gè)名叫 Snowball 的小容器，可以容納 80TB 數(shù)據(jù)。

這兩者都是按照物理方式轉(zhuǎn)移數(shù)據(jù)，而不是通過(guò)光纖，所以確實(shí)可伸縮。一項(xiàng)估測(cè)表明，轉(zhuǎn)移 100PB 數(shù)據(jù)，通過(guò) 1Gbps 的光纖需要 28 年，但是拖車幾天之內(nèi)就可以運(yùn)送到國(guó)家的另一邊。

所有這些都表明，開發(fā)者應(yīng)該開始關(guān)注數(shù)據(jù)在何處收集、會(huì)在何處用到。我們比過(guò)去收集了更多的數(shù)據(jù)，將數(shù)據(jù)轉(zhuǎn)移到合適的位置比以前更重要。就像 Wayne Gretzky 說(shuō)的，他的成功在于，提前規(guī)劃，并且滑到冰球?qū)⒁_(dá)到的位置、而不是到冰球現(xiàn)在的位置。

網(wǎng)站并沒(méi)有消亡；只是新的音頻接口逐漸興盛。Amazon, Google, Apple 鼓勵(lì)每個(gè)人說(shuō)出問(wèn)題，而不是站起來(lái)、走到電腦邊、用手指敲字，卻對(duì)問(wèn)題不聞不問(wèn)。

對(duì)程序員來(lái)說(shuō)，這意味著更多的工作量，因?yàn)樗械倪@些機(jī)制都有新的 API，比如 Alexa 燈光開關(guān)控制的新產(chǎn)品。如果你所在的公司想要連接這些音頻接口，你最好現(xiàn)在就研究。畢竟，鍵盤和 URL 是上世紀(jì)發(fā)明的。

服務(wù)器領(lǐng)域因線程模型一直很繁榮，這些模型使操作系統(tǒng)滿足程序員任何任性、低效、放縱的行為。不管程序員編寫的代碼是多么愚蠢的循環(huán)、多么無(wú)用的計(jì)算，操作系統(tǒng)需要通過(guò)在線程間切換來(lái)平衡性能。

然后 Node.js 提出 JavaScript 的回調(diào)編程模型，而且代碼運(yùn)行得很快，超出了大家對(duì)一個(gè)之前只是用于彈窗的玩具語(yǔ)言的期望。突然間創(chuàng)建新線程的劣勢(shì)變得明顯，Node.js 因此流行起來(lái)。

程序員表現(xiàn)不好，問(wèn)題就會(huì)出現(xiàn)，但是責(zé)任對(duì)他們來(lái)說(shuō)大部分是有益的。對(duì)程序員來(lái)說(shuō)，明顯的資源限制通常會(huì)導(dǎo)致代碼運(yùn)行得更快。

Node.js 領(lǐng)域也從前后臺(tái)的和諧統(tǒng)一中受益。一份代碼兩處運(yùn)行，對(duì)開發(fā)者來(lái)說(shuō)，遷移特性、賦值功能更加簡(jiǎn)單。因此，Node.js 領(lǐng)域成為互聯(lián)網(wǎng)上最熱門的技術(shù)棧。

曾經(jīng)PHP是一種完成幾個(gè)動(dòng)態(tài)頁(yè)面的簡(jiǎn)單方式。如果你需要更多樣化的，你可以在 HTML 標(biāo)簽之間嵌入簡(jiǎn)單的代碼。Web 開發(fā)人員接受 PHP 比較容易，但從硬核開發(fā)者的角度看，其速度之慢值得嘲諷。

不過(guò)這已經(jīng)成為過(guò)去，因?yàn)橄?WordPress 和 Facebook 這樣的 PHP 擁護(hù)者都在比誰(shuí)的 PHP 代碼更快，他們使用的是曾使 Java 成為高性能解決方案的即時(shí)編譯器技術(shù)（JIT）。

現(xiàn)在，像 HipHop 虛擬機(jī)和 PHP 7.0 這樣的工具的輸出速度可能是舊版本的兩倍。 Node.js 和 Java，看招吧。

計(jì)算機(jī)輔助課程不再新鮮，每個(gè)人都能享受到觀看視頻講座帶來(lái)的好處，包括快進(jìn)、慢播或者要求教授重復(fù)最后一段的操作。在線論壇也對(duì)舊的研討會(huì)議進(jìn)行了改進(jìn)，每次討論只有一個(gè)人可以主宰。

但是，網(wǎng)絡(luò)課程的本質(zhì)及其背后的技術(shù)不僅在于教育產(chǎn)業(yè)復(fù)雜化，更是讓學(xué)習(xí)能隨時(shí)隨地進(jìn)行而提出的要求。這正在改變生活，因?yàn)槿藗儾辉傩枰度胨哪甑拇罅繉W(xué)費(fèi)，用于那些可能與他們生活有關(guān)或無(wú)關(guān)的課程中。

在你不知道你是否需要使用編譯器工作時(shí)，為什么要在學(xué)習(xí)編譯器有關(guān)的課程呢？如果老板想從關(guān)系數(shù)據(jù)庫(kù)切換到 NoSQL 引擎，那么你就可以將時(shí)間投入到現(xiàn)代數(shù)據(jù)存儲(chǔ)的課程中。當(dāng)你需要時(shí)，你會(huì)收到最新的信息，而不需要過(guò)時(shí)的知識(shí)來(lái)擾亂你的思維。

附一篇

2016 前端開發(fā)技術(shù)年度最全盤點(diǎn)

本文將帶你客觀了解2016前端領(lǐng)域的變化：從下至上、由低到高的維度盤點(diǎn)了過(guò)去一年中Web前端領(lǐng)域發(fā)生的重要事件；理智分析發(fā)展趨勢(shì)，分析出影響2017前端領(lǐng)域的關(guān)鍵因素。同時(shí)，總結(jié)了業(yè)務(wù)類型變化給Web前端的工作所帶來(lái)的明顯差異，以及工程師整體技能方向的一些變化，切實(shí)給出前端工程師的個(gè)人技能提升方向。幫你在紛亂的前端江湖中，理清前端領(lǐng)域和自己發(fā)展的未來(lái)。

寫在前面

2016 年已經(jīng)過(guò)去了，像過(guò)去六年中的每一年一樣，Web前端領(lǐng)域又產(chǎn)生了“面目全非”而又“耳目一新”的變化，不但舊事物持續(xù)不斷地被淘汰，新事物也難保坐久江山，大有岌岌可危之勢(shì)。開源界如群雄逐鹿，不斷生產(chǎn)新的概念、新的框架、新的工具，去年中一些流行的技術(shù)今年大多得到了進(jìn)一步的演進(jìn)和升級(jí)，活躍度非常高，卻仍然不能保證前端的未來(lái)屬于它們。在今年整體資本市場(chǎng)冷卻的大環(huán)境下，to B的創(chuàng)業(yè)公司顯現(xiàn)出了較強(qiáng)的生命力，這種類型的業(yè)務(wù)也給Web前端的工作帶來(lái)了明顯的差異性，工程師整體技能方向也展露出一絲不一樣的分支。

更新的網(wǎng)絡(luò)與軟件環(huán)境

HTTP/2 的持續(xù)普及

今年中，幾乎所有的現(xiàn)代桌面瀏覽器都已經(jīng)支持了HTTP/2協(xié)議，移動(dòng)端依靠降級(jí)為SPDY依舊可以覆蓋幾乎所有平臺(tái)，這樣使得從協(xié)議上優(yōu)化頁(yè)面的性能成為了可能。同時(shí)，前端靜態(tài)資源打包的必要性成為了一定程度上的爭(zhēng)論焦點(diǎn)，打包合并作為傳統(tǒng)的前端性能優(yōu)化方案，它的存留對(duì)前端工程化影響極大，F(xiàn)acebook公司著名的靜態(tài)資源動(dòng)態(tài)打包方案的優(yōu)越性也會(huì)被弱化。社區(qū)上多篇文章紛紛發(fā)表對(duì)HTTP/2的性能實(shí)驗(yàn)數(shù)據(jù)，卻不盡相同。

在2017年，我相信所有大型站點(diǎn)都會(huì)切換HTTP/2，但依舊不會(huì)放棄對(duì)靜態(tài)資源打包合并的依賴。而且，對(duì)于Server Push等高級(jí)特性，也不會(huì)有太多的應(yīng)用。

Internet Explorer 8

三年前還在考慮兼容IE6的前端技術(shù)社區(qū)，在前不久天貓宣布不再支持IE8后又引起了一股躁動(dòng)。IE8是Windows XP操作系統(tǒng)支持的最高IE版本，放棄IE8意味著放棄了使用IE的所有XP用戶。

其實(shí)在2016年的今天，前端社區(qū)中框架、工具的發(fā)展早已不允許IE8的存在，Angular 早在1.3版本就果斷放棄了IE8，React 也在年初的v15版本上宣布放棄。在PC領(lǐng)域，你依舊可以使用像Backbone.js一樣的其他框架繼續(xù)對(duì)IE進(jìn)行支持，但無(wú)論是從研發(fā)效率上還是從運(yùn)行時(shí)效率上，放棄它都是更好的選擇。

由于對(duì)HTML5兼容性不佳，在2017年，相信IE9也會(huì)逐漸被社區(qū)放棄，以取得更好的性能、更少的代碼體積。

如何編寫(Java)Script

ES2016？ES2017？Babel!

去年定稿的ES2015（亦稱ES6）帶來(lái)了大量令人激動(dòng)的新語(yǔ)言特性，并快速被V8和SpiderMonkey所實(shí)現(xiàn)。但由于瀏覽器版本碎片化問(wèn)題，目前編寫生產(chǎn)環(huán)境代碼仍然以ES5為主。今年年中發(fā)布的ES2017帶來(lái)的新特性數(shù)量少的可憐，但這正好給了瀏覽器廠商消化ES2015的時(shí)間，在ES2017到來(lái)之前喘口氣——是的，明年的ES2017勢(shì)必又會(huì)帶來(lái)一大波新特性。

JS解釋引擎對(duì)新特性的支持程度并不能阻礙狂熱的開發(fā)者使用他們，在接下來(lái)的很長(zhǎng)時(shí)間，業(yè)界對(duì)Babel的依賴必然有增無(wú)減。Babel生態(tài)對(duì)下一代ECMAScript的影響會(huì)進(jìn)一步加大，人們通過(guò)先增加新的Babel-plugin，后向ECMA提案的方式成為了ECMAScript進(jìn)化的常態(tài)。開發(fā)者編寫的代碼能直接運(yùn)行在瀏覽器上的會(huì)越來(lái)越少。

但使用Babel導(dǎo)致的編譯后代碼體積增大的問(wèn)題并沒(méi)有被特別關(guān)注，由于polyfill可能被重復(fù)引入，部署到生產(chǎn)環(huán)境的代碼帶有相當(dāng)一部分冗余。

TypeScript

作為ECMAScript語(yǔ)言的超集，TypeScript在今年取得了優(yōu)異的成績(jī)，Angular 2放棄了傳說(shuō)中的AtScript，成為了TypeScript的最大客戶。人們可以像編寫Java一樣編寫JavaScript，有效提升了代碼的表述性和類型安全性。

但凡事有兩面，TypeScript的特性也在不斷升級(jí)，在生產(chǎn)環(huán)境中，你可能需要一套規(guī)范來(lái)約束開發(fā)者，防止濫用導(dǎo)致的不兼容，這反而增加了學(xué)習(xí)成本、應(yīng)用復(fù)雜性和升級(jí)安全性。個(gè)中優(yōu)劣，仍需有大量的工程實(shí)踐去積累經(jīng)驗(yàn)。

此外，TypeScript也可以看做一種轉(zhuǎn)譯器，與Babel有著類似的新特性支持。在2017年，我們期待TypeScript與Babel會(huì)發(fā)展成怎樣的一種微妙關(guān)系。

promise、generator 與 async/await

在回調(diào)地獄問(wèn)題上，近兩年我們不斷被新的方案亂花了眼。過(guò)去我們會(huì)利用async來(lái)簡(jiǎn)化異步流的設(shè)計(jì)，直到“正房”Promise的到來(lái)。但它們只是callback模式的語(yǔ)法糖，并沒(méi)有完全消除callback的使用。

ES2015帶來(lái)的generator/yield似乎成為了解決異步編程的一大法寶，雖然它并非為解決異步編程所設(shè)計(jì)的。但generaor的運(yùn)行是十分繁瑣的，因此另一個(gè)工具co又成為了使用generator的必備之選。Node.js社區(qū)的Koa框架初始就設(shè)計(jì)為使用generator編寫洋蔥皮一樣的控制流。

但曇花一現(xiàn)，轉(zhuǎn)眼間async/await的語(yǔ)法，配合Promise編寫異步代碼的方式立即席卷整個(gè)前端社區(qū)，雖然async/await仍然在ES2017的草案中，但在今天，不寫async/await立刻顯得你的設(shè)計(jì)落后社區(qū)平均水平一大截。

在Node.js上，v7已經(jīng)支持在harmony參數(shù)下的async/await直接解釋，在明年4月份的v8中，將會(huì)正式支持，屆時(shí)，Koa 2的正式版也會(huì)發(fā)布，幾乎完全摒棄了generator。

fetch

受到回調(diào)問(wèn)題的影響，傳統(tǒng)的XMLHttpRequest有被fetch API 取代之勢(shì)。如今，成熟的polyfill如whatwg-fetch、node-fetch、isomorphic-fetch在npm上的每日下載量都非常大，即便對(duì)于兼容性不好的移動(dòng)端，開發(fā)者也不愿使用繁瑣的AJAX。借助async/await的語(yǔ)法，使用fetch API能讓代碼更簡(jiǎn)潔。

Node.js服務(wù)與工具

Koa 2

Koa與流行的Express屬于“同根生”的關(guān)系，它們由同一團(tuán)隊(duì)打造。相比Express，新的Koa框架更輕量、更靈活。但Koa的設(shè)計(jì)在短時(shí)間內(nèi)曾經(jīng)出現(xiàn)了較大的變動(dòng)，這主要受到了async/await語(yǔ)法對(duì)異步編程的影響。在v2版本中，Koa的middleware拋棄generator轉(zhuǎn)而支持async，所有第三方middleware實(shí)現(xiàn)，要么自行升級(jí)，要么使用Koa-convert進(jìn)行包裝轉(zhuǎn)換。

目前Koa在Node.js社區(qū)的HTTP服務(wù)端框架中受到關(guān)注度比較高，不過(guò)其在npm上latest目前仍處于1.x階段，預(yù)計(jì)在2017年4月份發(fā)布Node.js v8后，就會(huì)升級(jí)到2.x。

Koa的輕量級(jí)設(shè)計(jì)意味著你需要大量第三方中間件去實(shí)現(xiàn)一個(gè)完整的Web應(yīng)用，目前鮮有看到對(duì)Koa的大規(guī)模重度使用，因此也就對(duì)其無(wú)從評(píng)價(jià)。相信在明年，越來(lái)越多的產(chǎn)品應(yīng)該會(huì)嘗試部署Koa 2，屆時(shí)，對(duì)第三方資源的依賴沖突也會(huì)尖銳起來(lái)，這需要一個(gè)過(guò)程才能讓Koa的生態(tài)完備起來(lái)。預(yù)計(jì)在2018年，我們會(huì)得到一個(gè)足夠健壯的Koa技術(shù)棧。這會(huì)促進(jìn)Node.js在服務(wù)端領(lǐng)域的擴(kuò)展，輕量級(jí)的Web服務(wù)將會(huì)逐漸成為市場(chǎng)上的主流。

框架紛爭(zhēng)

jQuery已死？

今年六月份jQuery發(fā)布了3.0版本，距離2.0發(fā)布已經(jīng)有三年多的時(shí)間，但重大的更新幾乎沒(méi)有。由于老舊瀏覽器的逐漸放棄和升級(jí)，jQuery需要處理的瀏覽器兼容性問(wèn)題越來(lái)越少，專注于API易用性和效率越來(lái)越多。

隨著如Angular、React、Ember、Vue.js等大量具備視圖數(shù)據(jù)單雙向綁定能力的框架被普及，使用jQuery編寫指令式的代碼操作DOM的人越來(lái)越少。早在2015年便有人聲稱jQuery已死，社區(qū)中也進(jìn)行了大量雷同的討論，今天我們看到確實(shí)jQuery的地位已大不如前，著名的sizzle選擇器在今天已完全可由querySelector原生方法替代，操作DOM也可以由框架根據(jù)數(shù)據(jù)的變動(dòng)自動(dòng)完成。

明年jQuery在構(gòu)建大型前端產(chǎn)品的過(guò)程中的依賴會(huì)被持續(xù)弱化，但其對(duì)瀏覽器特性的理解和積淀將對(duì)現(xiàn)有的和未來(lái)的類Angular的MVVM框架的開發(fā)依舊具有很大的借鑒意義。

Angular 2

好事多磨，Angular 2的正式版終于在今年下半年發(fā)布，相比于1.x，新的版本幾乎是完全重新開發(fā)的框架，已經(jīng)很難從設(shè)計(jì)中找到1.x的影子。陡峭的學(xué)習(xí)曲線也隨之而來(lái)，npm、ES2015 Modules、Decorator、TypeScript、Zone.js、RxJS、JIT/AOT、E2E Test，幾乎都是業(yè)界這兩年中的最新概念，這著實(shí)給初學(xué)者帶來(lái)了不小的困難。

Angular 2也更面向于開發(fā)單頁(yè)應(yīng)用（SPA），這是對(duì)ES2015 Modules語(yǔ)法描述的模塊進(jìn)行打包（bundle）的必然結(jié)果，因此Angular 2也更依賴于Webpack等“bundler”工具。

雖然Angular 聲稱支持TypeScript、ECMAScript和Dart三種語(yǔ)言，不過(guò)顯然業(yè)界對(duì)Dart沒(méi)什么太大興趣，而對(duì)于ECMAScript和TypeScript，兩種語(yǔ)言模式下Angular 2在API和構(gòu)建流程上都有著隱式的（文檔標(biāo)注不明的）差異化，這必然會(huì)給開發(fā)者以困擾。加上業(yè)界第三方工具和組件的支持有限，TypeScript幾乎是現(xiàn)在開發(fā)者唯一的選擇。

此外，Angular團(tuán)隊(duì)已聲明并沒(méi)有完全放棄對(duì)1.x組件的支持，通過(guò)特有的兼容API，你可以在2.x中使用針對(duì)1.x開發(fā)的組件。鑒于不明確的風(fēng)險(xiǎn)，相信很少有團(tuán)隊(duì)愿意這樣折騰。

現(xiàn)在在產(chǎn)品中使用Angular 2，在架構(gòu)上，你需要考慮生產(chǎn)環(huán)境和開發(fā)環(huán)境下兩種完全不同的構(gòu)建模式，也就是JIT和AOT，這需要你有兩套不一樣的編譯流程和配置文件。在不同環(huán)境下模塊是否符合期望，可以用E2E、spec等方式來(lái)進(jìn)行自動(dòng)化測(cè)試，好的，那么Angular 2的測(cè)試API又可能成了技術(shù)壁壘，它的復(fù)雜度可能更甚Angular本身?？梢源_信，在業(yè)務(wù)壓力的迫使下，絕大部分團(tuán)隊(duì)都會(huì)放棄編寫測(cè)試。

總之，Angular 2是一個(gè)非常具有競(jìng)爭(zhēng)力的框架，其設(shè)計(jì)非常具有前瞻性，但也由于太過(guò)復(fù)雜，很多特性都會(huì)成為雞肋，被開發(fā)者所無(wú)視。由于React和Vue.js的競(jìng)爭(zhēng)，Angular 2對(duì)社區(qū)的影響肯定不如其前輩1.x版本，且其更高級(jí)的特性如Server Render還沒(méi)有被工程化實(shí)踐，因此相信業(yè)界還會(huì)持續(xù)觀望，甚至要等到下一個(gè)4.x版本的發(fā)布。

Vue.js 2.0

Vue.js 絕對(duì)是類MVVM框架中的一匹黑馬，由作者一人打造，更可貴的是作者還是華人。Vue.js在社區(qū)內(nèi)的影響非常之大，特別是2.0的發(fā)布，社區(qū)快速生產(chǎn)出了無(wú)數(shù)基于Vue.js的解決方案，這主要還是受益于其簡(jiǎn)單的接口API和友好的文檔。可見作為提供商，產(chǎn)品的簡(jiǎn)單易用性顯得尤為重要。在性能上，Vue.js基于ES5 Setter，得到了比Angular 1.x臟檢查機(jī)制成倍的性能提升。而2.0在模塊化上又更進(jìn)一步，開發(fā)難度更低，維護(hù)性更好?？梢哉f(shuō)Vue.js準(zhǔn)確地戳中了普通Web開發(fā)者的痛點(diǎn)。在國(guó)內(nèi)，Vue.js與Weex達(dá)成了合作，期待能給社區(qū)帶來(lái)怎樣的驚喜。

React

目前看來(lái)，React似乎仍是今年最流行的數(shù)據(jù)視圖層解決方案，并且?guī)缀跻呀?jīng)成為了每名前端工程師的標(biāo)配技能。今年React除了版本從0.14直接躍升至15，放棄了IE8以外，并沒(méi)有更多爆發(fā)式的發(fā)展。人們對(duì)于使用JSX語(yǔ)法編寫Web應(yīng)用已經(jīng)習(xí)以為常，就像過(guò)去十年間寫jQuery一樣。

React的代碼在維護(hù)性能上顯而易見，如果JSX編寫得當(dāng)，在重渲染性能上也具備優(yōu)勢(shì)，但如果只部署在瀏覽器環(huán)境中，那么首屏性能將會(huì)受到負(fù)面影響，畢竟在現(xiàn)階段，純前端渲染仍然快不過(guò)后端渲染，況且后端具備天生的chunked分段輸出優(yōu)勢(shì)。我們?cè)跇I(yè)界中可以看到一些負(fù)面的案例，比如某新聞應(yīng)用利用React全部改寫的case，就是對(duì)React的一種誤用，完全不顧其場(chǎng)景劣勢(shì)。

圍繞著React發(fā)展的替代品和配套工具依舊很活躍，preact以完全兼容的API和小巧的體積為賣點(diǎn)，inferno以更快的速度為賣點(diǎn)，等等。每個(gè)框架都想在Virtual DOM上有所創(chuàng)新，但它們的提升都不是革命性的，由此而帶來(lái)的第三方插件不兼容性，這種風(fēng)險(xiǎn)是開發(fā)者不愿承擔(dān)的，筆者認(rèn)為它們最大的意義在于能為React的內(nèi)部實(shí)現(xiàn)提供另外的思路。就像在自然界，生物多樣性是十分必要的，雜交能帶來(lái)珍貴的進(jìn)化優(yōu)勢(shì)。

React-Native

今年是React-Native（以下簡(jiǎn)稱RN）支持雙端開發(fā)的第一年，不斷有團(tuán)隊(duì)分享了自己在RN上的實(shí)踐成果，似乎前途一片大好，RN確實(shí)有效解決了傳統(tǒng)客戶端受限于發(fā)版周期、H5受限于性能的難題，做到了魚和熊掌兼得的理想目標(biāo)。

但我們?nèi)匀恍枰|(zhì)疑：

首先，RN目前以兩周為周期發(fā)布新版本，沒(méi)有LTS，每個(gè)版本向前不兼容。也就是說(shuō)，你使用0.39.0的版本編寫bundle代碼，想運(yùn)行在0.35.0的runtime上，這幾乎會(huì)100%出問(wèn)題。在這種情況下，如何制定客戶端上RN的升級(jí)策略？如果升級(jí)，那么業(yè)務(wù)上如何針對(duì)一個(gè)以上的runtime版本編寫代碼？如果不升級(jí)，那么這意味著你需要自己維護(hù)一個(gè)LTS。要知道目前每個(gè)RN的版本都會(huì)有針對(duì)前版本的bug fix，相信沒(méi)有團(tuán)隊(duì)有精力可以在一個(gè)老版本上同步這些，如果不能，那業(yè)務(wù)端面對(duì)的將是一個(gè)始終存在bug的runtime，其開發(fā)心理壓力可想而知。

其次，雖然RN聲稱支持Android與iOS雙端，但在實(shí)踐中卻存在了極多系統(tǒng)差異性。有些體現(xiàn)在了RN文檔中，有一些則體現(xiàn)在了issue中，包括其他一些問(wèn)題，GitHub上RN的近700個(gè)issue足以讓人望而卻步。如果不能高效處理開發(fā)中遇到的各種匪夷所思的問(wèn)題，那么工期就會(huì)出現(xiàn)嚴(yán)重風(fēng)險(xiǎn)。

此外，RN在Android和iOS上的性能也不盡相同，Android上更差一些，即便你完成了整個(gè)業(yè)務(wù)功能，卻還要在性能優(yōu)化上消耗精力。并且無(wú)論如何優(yōu)化，單線程模型既要實(shí)現(xiàn)流暢的轉(zhuǎn)場(chǎng)動(dòng)畫，又要操作一系列數(shù)據(jù)，需要很高的技巧才能保證可觀的性能表現(xiàn)。在具體的實(shí)踐中，對(duì)于H5，往往由于時(shí)間關(guān)系，業(yè)務(wù)上先會(huì)上一個(gè)還算過(guò)得去的版本，過(guò)后再啟動(dòng)性能優(yōu)化。然而對(duì)于RN，很有可能達(dá)到“過(guò)得去”的標(biāo)準(zhǔn)都需要大量的重構(gòu)工作。

再次，RN雖然以Native渲染元素，但畢竟是運(yùn)行在JavaScript Core內(nèi)核之上，依舊是單線程，相對(duì)于H5這并沒(méi)有對(duì)性能有革命性質(zhì)的提升。Animated動(dòng)畫、大ListView滾動(dòng)都是老生常談的性能瓶頸，為了解決一些復(fù)雜組件所引起的性能和兼容性問(wèn)題，諸多團(tuán)隊(duì)紛紛發(fā)揮主動(dòng)能動(dòng)性，自己建設(shè)基于Native的高性能組件，

這有兩方面問(wèn)題，一是不利于分發(fā)共享，因?yàn)樗鼑?yán)重依賴特定的客戶端環(huán)境，二是它仍依賴客戶端發(fā)版，仍需要客戶端的開發(fā)，違背了RN最最重要的初衷?？梢韵胂螅诖罅款l繁引用Native組件后，RN又退化成了H5+Hybrid模式，其UI的高性能優(yōu)勢(shì)將會(huì)在設(shè)備性能不斷升級(jí)下被削弱，同時(shí)其無(wú)stable版本反而給開發(fā)帶來(lái)了更多不可預(yù)測(cè)的風(fēng)險(xiǎn)變量。

最后，RN仍然難以調(diào)試和測(cè)試。特別是依賴了特定端上組件之后，本地的自動(dòng)化測(cè)試幾乎成為了不可能，而絕大多數(shù)客戶端根本不支持自動(dòng)化測(cè)試。而調(diào)試只能利用remote debugger有限的能力，在性能分析上都十分不便。

可以說(shuō)RN的出現(xiàn)帶給了移動(dòng)開發(fā)以獨(dú)特的新視角，使得利用JavaScript開發(fā)Native成為了可能，NativeScript、Weex等類似的解決方案也發(fā)展開來(lái)。顯然RN目前最大的問(wèn)題仍然是不夠成熟和穩(wěn)定，利用RN替代Native依然存在著諸多風(fēng)險(xiǎn)，這對(duì)于重量級(jí)的、長(zhǎng)期維護(hù)的客戶端產(chǎn)品可能并不是特別適合，比如Facebook自己。RN的優(yōu)勢(shì)顯而易見，但其問(wèn)題也是嚴(yán)重的，需要決策者對(duì)個(gè)方面利弊都有所了解，畢竟這種試錯(cuò)的成本不算小。

由于時(shí)間關(guān)系，市場(chǎng)上并沒(méi)有一個(gè)產(chǎn)品在RN的應(yīng)用上有著足夠久的實(shí)踐經(jīng)驗(yàn)，大部分依然屬于“我們把RN部署到客戶端了”的階段，我們也無(wú)法預(yù)測(cè)這門技術(shù)的長(zhǎng)久表現(xiàn)，現(xiàn)在評(píng)價(jià)RN的最終價(jià)值還為時(shí)尚早。在2017年，期待RN團(tuán)隊(duì)能做出更長(zhǎng)足的進(jìn)步，但不要太樂(lè)觀，以目前的狀態(tài)來(lái)看，想達(dá)到stable狀態(tài)還是有著相當(dāng)大的難度。

Redux 與 Mobx

Redux 成功成為了 React 技術(shù)棧中的最重要成員之一。與Vue.js一樣，Redux也是憑借著比其他Flux框架更簡(jiǎn)單易懂的API才能脫穎而出。不過(guò)已經(jīng)很快有人開始厭煩它每寫一個(gè)應(yīng)用都要定義action、reducer、store以及一大堆函數(shù)式調(diào)用的繁瑣做法了。

Mobx也是基于ES5 setter，讓開發(fā)者可以不用主動(dòng)調(diào)用action函數(shù)就可以觸發(fā)視圖刷新，它只需要一個(gè)store對(duì)象以及幾個(gè)decorator就能完成配置，確實(shí)比Redux簡(jiǎn)單得多。

在數(shù)據(jù)到視圖同步上，無(wú)論使用什么樣的框架，都有一個(gè)至關(guān)重要的問(wèn)題是需要開發(fā)者自己操心，那就是在眾多數(shù)據(jù)變動(dòng)的情形下，如何保證視圖以最少的但合理的頻率去刷新，以節(jié)省極其敏感的性能消耗。在Redux或Mobx上都會(huì)出現(xiàn)這個(gè)問(wèn)題，而Mobx尤甚。為了配合提升視圖的性能，你依然需要引入action、transaction等高級(jí)概念。在控制流與視圖分離的架構(gòu)中，這是開發(fā)者無(wú)可避免的關(guān)注點(diǎn)，而對(duì)于Angular、Vue.js，框架會(huì)幫你做很多事情，開發(fā)者需要考慮的自然少了許多。

Bootstrap

BootstrapBootstrap 4處于alpha階段已經(jīng)非常久了，即使現(xiàn)在3.x已經(jīng)停止了維護(hù)，它似乎受到了Twitter公司業(yè)務(wù)不景氣的影響，GitHub上的issue還非常多。Bootstrap是建設(shè)內(nèi)部平臺(tái)最佳的CSS框架，特別是對(duì)于那些對(duì)前端不甚了解的后端工程師。我們不清楚Bootstrap還能堅(jiān)持多久，如果Twitter不得不放棄它，最好的歸宿可能是把它交給第三方開源社區(qū)去維護(hù)。

工程化與架構(gòu)

Rollup 與 Webpack 2

Rollup是近一年興起的又一打包工具，其最大賣點(diǎn)是可以對(duì)ES2015 Modules的模塊直接打包，以及引入了Tree-Shaking算法。通過(guò)引入Babel-loader，Webpack一樣可以對(duì)ES2015 Modules進(jìn)行打包，于是Rollup的亮點(diǎn)僅在于Tree-Shaking，這是一種能夠去除冗余，減少代碼體積的技術(shù)。通過(guò)分析AST（抽象語(yǔ)法樹），Rollup可以發(fā)現(xiàn)那些不會(huì)被使用的代碼，并去除它。

不過(guò)Tree-Shaking即將不是Rollup的專利了，Webpack 2也將支持，并也原生支持ES6 Modules。這可以說(shuō)是“旁門左道”對(duì)主流派系進(jìn)行貢獻(xiàn)的一個(gè)典型案例。

Webpack是去年大熱的打包工具，儼然已經(jīng)成為了替代grunt/gulp的最新構(gòu)建工具，但顯然并不是這樣。筆者一直認(rèn)為Webpack作為一個(gè)module bundler，做了太多與其無(wú)關(guān)的事情，從而表象上看來(lái)這就是一個(gè)工程構(gòu)建工具。經(jīng)典的構(gòu)建需要有任務(wù)的概念，然后控制任務(wù)的執(zhí)行順序，這正是Ant、Grunt、Gulp做的事情。Webpack不是這樣，它最重要的概念是entry，一個(gè)或者多個(gè)，它必須是類JavaScript語(yǔ)言編寫的磁盤文件，所有其他如CSS、HTML都是圍繞著entry被處理的。估計(jì)你很難一眼從配置文件中看出Webpack對(duì)當(dāng)前項(xiàng)目進(jìn)行了怎樣的“構(gòu)建”，不過(guò)似乎社區(qū)中并沒(méi)有人提出過(guò)異議，一切都運(yùn)行得很好。

題外話：如何使用Webpack構(gòu)建一個(gè)沒(méi)有任何JavaScript代碼的工程？新的Angular 2使用Webpack 2編譯效果更加，不過(guò)，已經(jīng)提了一年的Webpack 2，至今仍處于beta階段，好在現(xiàn)在已經(jīng)rc，相信離release不遠(yuǎn)了。

npm、jspm、Bower與Yarn

在模塊管理器這里，npm依舊是王者，但要說(shuō)明的是，npm的全稱是node package mamager，主要用來(lái)管理運(yùn)行在Node上的模塊，但現(xiàn)在卻托管了大量只能運(yùn)行在瀏覽器上的模塊。造成這種現(xiàn)象的幾個(gè)原因：

Webpack的大量使用，使得前端也可以并習(xí)慣于使用CommonJS類型的模塊；

沒(méi)有更合適的替代者，Bower以前不是，以后更不會(huì)是。

前端的模塊化規(guī)范過(guò)去一直處于戰(zhàn)國(guó)紛爭(zhēng)的年代。在Node上CommonJS沒(méi)什么意見。在瀏覽器上，雖然現(xiàn)在有了ES2015 Modules，卻缺少了模塊加載器，未來(lái)可能是SystemJS，但現(xiàn)在仍處于草案階段。無(wú)論哪種，都仍處于JavaScript語(yǔ)言層面，而完整的前端模塊化還要包括CSS與HTML，以及一些二進(jìn)制資源。目前最貼近的方案也就只能是JSX+CSS in JS的模式了，這在Webpack環(huán)境下大行其道。這種現(xiàn)象甚至影響了Angular 2、Ember 2等框架的設(shè)計(jì)。從這點(diǎn)看來(lái)，jspm只是一個(gè)加了層包裝的殼子，完全沒(méi)有任何優(yōu)勢(shì)。

npm本身也存在著各種問(wèn)題，這在實(shí)踐中總會(huì)影響效率、安全以及一致性，F(xiàn)acebook果斷地出品了Yarn——npm的替代升級(jí)版，支持離線模式、嚴(yán)格的依賴版本管理等在工程中非常實(shí)用的特性。

至于前端模塊化，JavaScript有CommonJS和ES2015 Modules就夠了，但工程中的組件，可能還需要在不同的框架環(huán)境中重復(fù)被開發(fā)，它們依舊不兼容。未來(lái)的話，WebComponents可能是一個(gè)比較優(yōu)越的方案。

同構(gòu)

同構(gòu)的設(shè)計(jì)在軟件行業(yè)早就被提出，不過(guò)在Web前端，還是在Node.js、特別是React的出現(xiàn)后，才真正成為了可能，因?yàn)镽eact內(nèi)核的運(yùn)行并不依賴于瀏覽器DOM環(huán)境。

React的同構(gòu)是一個(gè)比較低成本的方案，只要注意代碼的執(zhí)行環(huán)境，前后端確實(shí)可以共享很大一部分代碼，隨之帶來(lái)的一大收益是有效克服了SPA這種前端渲染的頁(yè)面在首屏性能上的瓶頸，這是所有具備視圖能力的框架Angular、Vue.js、React等的共性問(wèn)題，而現(xiàn)在，它們都在一種程度上支持server render。

可以想到的做前后端同構(gòu)面臨的幾個(gè)問(wèn)題：

靜態(tài)資源如何引入，CSS in JS模式需要考慮在Node.js上的兼容性；

數(shù)據(jù)接口如何fetch，在瀏覽器上是AJAX，在Node.js上是什么；

如何做路由同構(gòu)，瀏覽器無(wú)刷新切換頁(yè)面，新路由在服務(wù)端可用；

大量DOM渲染如何避免阻塞Node.js的執(zhí)行進(jìn)程。

目前GitHub上star較多的同構(gòu)框架包括Vue.js的nuxt和React的next.js，以及數(shù)據(jù)存儲(chǔ)全包的meteor?？梢钥隙ǖ氖?，不論它們是否能部署在生產(chǎn)環(huán)境中，都不可能滿足你的所有需求，適當(dāng)?shù)闹匦录軜?gòu)是必要的，在這個(gè)新的領(lǐng)域，沒(méi)有太多的經(jīng)驗(yàn)可以借鑒。

未來(lái)技術(shù)與職業(yè)培養(yǎng)

大數(shù)據(jù)方向

越來(lái)越多做toB業(yè)務(wù)的公司對(duì)前端的需求都是在數(shù)據(jù)可視化上，或者更通俗一些——報(bào)表。這個(gè)部分在從前通常都是前端工程師嗤之以鼻的方向，認(rèn)為無(wú)聊、沒(méi)技術(shù)。不過(guò)在移動(dòng)端時(shí)代，特別是大數(shù)據(jù)時(shí)代，對(duì)此類技能的需求增多，技術(shù)的含金量也持續(xù)提升。根據(jù)“面向工資編程”的原則，一定會(huì)有大量工程師加入進(jìn)來(lái)。

對(duì)這個(gè)方向的技術(shù)技能要求是Canvas、WebGL，但其實(shí)絕大多數(shù)需求都不需要你直接與底層API打交道，已經(jīng)有大量第三方工具幫你做到了，不乏非常優(yōu)秀的框架。如百度的ECharts，國(guó)外的Chart.js、Highcharts、D3.js等等，特別是D3.js，幾乎是大數(shù)據(jù)前端方向的神器，非常值得學(xué)習(xí)。

話說(shuō)回來(lái)，作為工程師，心存憂患意識(shí)，一定不能以學(xué)會(huì)這幾款工具就滿足，在實(shí)際的業(yè)務(wù)場(chǎng)景中，更多的需要你擴(kuò)展框架，生產(chǎn)自己的組件，這需要你具備一定的數(shù)學(xué)、圖形和OpenGL底層知識(shí)，可以說(shuō)是非常大的技術(shù)壁壘和入門門檻。

WebVR

今年可以說(shuō)是VR技術(shù)爆發(fā)式的一年，市場(chǎng)上推出了多款VR游戲設(shè)備，而淘寶更是開發(fā)出了平民的buy+購(gòu)物體驗(yàn)，等普及開來(lái)，幾乎可以顛覆傳統(tǒng)的網(wǎng)上購(gòu)物方式。

VR的開發(fā)離不開對(duì)3D環(huán)境的構(gòu)建，WebVR標(biāo)準(zhǔn)還在草案階段，A-Frame可以用來(lái)體驗(yàn)，另一個(gè)three.js框架是一個(gè)比較成熟的構(gòu)建3D場(chǎng)景的工具，除了能在未來(lái)的VR應(yīng)用中大顯身手，同樣也在構(gòu)建極大豐富的3D交互移動(dòng)端頁(yè)面中顯得必不可少，淘寶就是國(guó)內(nèi)這方面的先驅(qū)。

WebAssembly

asm.js已發(fā)展成WebAssembly，由谷歌、微軟、蘋果和Mozilla四家共同推動(dòng)，似乎是非常喜人樂(lè)見的事情，畢竟主要瀏覽器內(nèi)核廠商都在這里了。不過(guò)合作的一大問(wèn)題就是低效，今年終于有了可以演示的demo，允許編寫C++代碼來(lái)運(yùn)行在瀏覽器上了，你需要下載一大堆依賴庫(kù)，以及一次非常耗時(shí)的編譯，不過(guò)好歹是個(gè)進(jìn)步。

短時(shí)間內(nèi)，我們都不太可能改變使用JavaScript編寫前端代碼的現(xiàn)狀，Dart失敗了，只能期望于未來(lái)的WebAssembly。有了它，前端在運(yùn)行時(shí)效率、安全性都會(huì)上一個(gè)臺(tái)階，其他隨之而來(lái)的問(wèn)題，就只能等到那一天再說(shuō)了。

WebComponents

WebComponents能帶給我們什么呢？HTML Template、Shadow DOM、Custom Element和HTML Import？是的，非常完美的組件化系統(tǒng)。Angular、React的組件化系統(tǒng)中，都是以Custom Element的方式組合HTML，但這都是假象，它們最終都會(huì)被編譯成JavaScript才會(huì)執(zhí)行。但WebComponents不一樣，Custom Element原生就可以被瀏覽器解析，DOM元素本身的方法都可以自定義，而且元素內(nèi)部的子元素、樣式，由于Shadow DOM的存在，不會(huì)污染全局空間，真正成為了一個(gè)沙箱，組件化就應(yīng)該是這個(gè)樣子，外部只關(guān)心接口，不關(guān)心也不能操縱內(nèi)部的實(shí)現(xiàn)。

當(dāng)前的組件化，無(wú)不依賴于某一特定的框架環(huán)境，或者是Angular，或者是React，想移植就需要翻盤推倒重來(lái)，也就是說(shuō)他們是不兼容的。有了WebComponents，作為瀏覽器廠商共同遵循和支持的標(biāo)準(zhǔn)，這一現(xiàn)狀將極有可能被改寫。

未來(lái)的前端組件化分發(fā)將不會(huì)是npm那么簡(jiǎn)單，可能只是引用一個(gè)HTML文件，更有可能的是包含CSS、HTML、JavaScript和其他二進(jìn)制資源的一個(gè)目錄。

目前只有最新的Chrome完全支持WebComponents的所有特性，所以距離真正應(yīng)用它還尚需時(shí)日。由于技術(shù)上的限制，WebComponents polyfill的能力都非常受限，Shadow DOM不可能實(shí)現(xiàn)，而其他三者則更多需要離線編譯實(shí)現(xiàn)，可以參考Vue.js 2的實(shí)現(xiàn)，非常類似于WebComponents。

關(guān)于微信小程序

微信小程序?qū)τ诮衲瓴坏貌徽f(shuō)，但筆者卻也無(wú)話可說(shuō)。依托于龐大的用戶量，微信官方出品了自有的一套開發(fā)技術(shù)棧，只能說(shuō)給繁雜的前端開發(fā)又填了一個(gè)角色——微信前端工程師。

最后總結(jié)

工程化

首先，現(xiàn)在業(yè)界都在大談前端工程化，人人學(xué)構(gòu)建，個(gè)個(gè)會(huì)打包。鄙人認(rèn)為，工程化的要點(diǎn)在于“平衡諸方案利弊，取各指標(biāo)的加權(quán)收益最大化”。僅僅加入了項(xiàng)目構(gòu)建是遠(yuǎn)遠(yuǎn)不夠的，在實(shí)踐中，我們經(jīng)常需要考慮的方向大可以分為兩種：一是研發(fā)效率，這直接應(yīng)該響應(yīng)業(yè)務(wù)需求的能力；二是運(yùn)行時(shí)性能，這直接影響用戶的使用體驗(yàn)，同時(shí)也是產(chǎn)品經(jīng)理所關(guān)心的。這兩點(diǎn)都直接影響了公司的收入和業(yè)績(jī)。

具體到細(xì)節(jié)的問(wèn)題上來(lái)，比如說(shuō)：

靜態(tài)資源如果組織和打包，對(duì)于具備眾多頁(yè)面的產(chǎn)品，考慮到不斷的迭代更新，如何打包能讓用戶的代碼下載量最少（性能）？不要說(shuō)使用Webpack打成一個(gè)包，也不要說(shuō)編譯common chunk就萬(wàn)事大吉了，難道還需要不斷地調(diào)整編譯腳本（效率）？改錯(cuò)了怎么辦？有測(cè)試方案么？

利用Angular特別是React構(gòu)建純前端渲染頁(yè)面，首屏性能如何保證（性能）？引入服務(wù)端同構(gòu)渲染，好的，那么服務(wù)端由誰(shuí)來(lái)編寫？想來(lái)必是由前端工程師來(lái)編寫，那么服務(wù)端的數(shù)據(jù)層架構(gòu)是怎么樣的？運(yùn)維角度看，前端如何保證服務(wù)的穩(wěn)定（效率）？

組件化方案如何制定（效率）？如果保證組件的分發(fā)和引用的便捷性？如何保證組件在用戶端的即插即用（性能）？

對(duì)于工程師來(lái)說(shuō)，首先需要量化每個(gè)指標(biāo)的權(quán)重，然后對(duì)于備選方案，逐個(gè)計(jì)算加權(quán)值，取最大值者，這才是科學(xué)的技術(shù)選型方法論。

然而在業(yè)界，很少能看到針對(duì)工程化的更深入分享和討論，大多停留在“哪個(gè)框架好”，“使用XXX實(shí)現(xiàn)XXX”的階段，往往是某一特定方向的優(yōu)與劣，很少有科學(xué)的全局觀。甚至只看到了某一方案的優(yōu)勢(shì)，對(duì)其弊端和可持續(xù)性避而不談。

造成這種現(xiàn)狀的原因是多方面的，一是技術(shù)上，工程師能力的原因并沒(méi)有考慮得到，二是政治上，工程師需要快速實(shí)現(xiàn)某一目標(biāo)，以取得可見的KPI收益，完成團(tuán)隊(duì)的績(jī)效目標(biāo)，但更多的可能是，國(guó)內(nèi)絕大多數(shù)產(chǎn)品的復(fù)雜性都還不夠高，根本無(wú)需考慮長(zhǎng)久的可持續(xù)發(fā)展和大規(guī)模的團(tuán)隊(duì)合作對(duì)于技術(shù)方案的影響。

因此，你必須接受的現(xiàn)狀是，無(wú)論你是否使用CSS預(yù)處理器、使用Webpack還是Grunt、使用React還是Angular，使用RN還是Hybrid，對(duì)于產(chǎn)品極有可能都不是那么地敏感和重要，往往更取決于決策者的個(gè)人喜好。

角色定位

確實(shí)，近兩年，Web前端工程師開始不夠老實(shí)，要么用Node.js插手服務(wù)端開發(fā)，要么用RN插手客戶端開發(fā)。如何看待這些行為呢？

鄙人以為，涉足服務(wù)端開發(fā)是沒(méi)問(wèn)題的，因?yàn)橹簧婕暗戒秩緦用妫€是屬于“前端”的范疇的。況且，在實(shí)際的工程實(shí)踐中，已經(jīng)可以證明，優(yōu)秀的前端研發(fā)體系確實(shí)離不開服務(wù)端的參與，想想Facebook的BigPipe。

不過(guò)，這需要服務(wù)端良好的分層架構(gòu)，數(shù)據(jù)與渲染完全解耦分離，后端工程師只負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)的CRUD，并提供接口，前端工程師從接口中獲取數(shù)據(jù)，并推送到瀏覽器上。數(shù)據(jù)解耦是比接口解耦更加優(yōu)越的方案。因此現(xiàn)在只要你的服務(wù)端架構(gòu)允許，Node.js作為Web服務(wù)已經(jīng)比較成熟，前端負(fù)責(zé)服務(wù)端渲染是完全沒(méi)有問(wèn)題的。

前端涉足客戶端開發(fā)也是合理的，畢竟都運(yùn)行在用戶端，也屬于前端的范疇。拋開阿里系的Weex鄙人不甚了解，NativeScript、RN都還缺乏大規(guī)模持續(xù)使用的先例，這是與涉足服務(wù)端領(lǐng)域的不同，客戶端上的方案都還不夠成熟，工具的限制阻礙了前端向客戶端的轉(zhuǎn)型，仍然需要時(shí)間的考驗(yàn)。不過(guò)時(shí)間可能不會(huì)很多，未來(lái)的Web技術(shù)依托高性能硬件以及普及的WebGL、WebRTC、Payment API等能力，在性能和功能上都會(huì)挑戰(zhàn)Native的地位。最差的情況，還可以基于Hybrid，利用Native適當(dāng)擴(kuò)展能力，這就是合作而非競(jìng)爭(zhēng)關(guān)系了。

總之前端工程師的本仍然在瀏覽器上，就這一點(diǎn)，范圍就足夠廣使得沒(méi)人有敢言自己真正“精通”前端。如果條件允許的話，特別是技術(shù)成熟之后，涉獵其他領(lǐng)域也是鼓勵(lì)的。

寫在最后

在各種研發(fā)角色中，前端注定是一個(gè)比較心累的一個(gè)。每一年的年末，我們都能看到幾乎完全不一樣的世界，這背后是無(wú)數(shù)前端人燒腦思考、激情迸發(fā)的結(jié)果。無(wú)論最終產(chǎn)品的流行與否，都推動(dòng)著前端技術(shù)領(lǐng)域的高速更新?lián)Q代。正是印證了那一句“唯有變化為不變”。作為業(yè)務(wù)線的研發(fā)工程師，我們的職責(zé)是甄選最佳組合方案，取得公司利益最大化。這個(gè)“最佳”的涉獵面非常廣，取決于設(shè)計(jì)者的技術(shù)視野廣度，也有關(guān)于決策者的管理經(jīng)驗(yàn)，從來(lái)都不是一件簡(jiǎn)單的事。

未來(lái)的Web前端開發(fā)體驗(yàn)一定是更豐富的，依托WebComponents的標(biāo)準(zhǔn)化組件體系，基于WebAssembly的高性能運(yùn)行時(shí)代碼，以及背靠HTTP/2協(xié)議的高速資源加載，前端工程師不必在性能上、兼容性上分散太多精力，從而可以專注于開發(fā)具備豐富式交互體驗(yàn)的下一代Web APP，可能是VR，也可能是游戲。

在迎接2017的同時(shí)，我們?nèi)匀灰龊眯睦頊?zhǔn)備，新的概念、新的框架和工具以及新的語(yǔ)法依舊會(huì)源源不斷的生產(chǎn)出來(lái)，不完美的現(xiàn)狀也依舊會(huì)持續(xù)。

作者 | 圖文來(lái)自網(wǎng)絡(luò)、如涉及版權(quán)問(wèn)題，請(qǐng)聯(lián)系我們以便處理。文章內(nèi)容純屬作者個(gè)人觀點(diǎn)，不代表本網(wǎng)觀點(diǎn)。

-END-