摘要：随着互聯網的進步，傳統的Web技術已經不能滿足于人們對交互體驗的更高要求，使用ReactJS，bootstrap，AngularJS，H5等新興技術成為未來前端開發的必然選擇；展示了近幾年興起的新興技術和工程化思想，分析其優缺點；指出應用和應對這些技術是未來幾年前端發展的重要課題。
關鍵詞：前端發展；前端模塊化；AngularJs；HTML5；Webpack；Backbonejs；Reactjs引言
近年來随着前端領域的大跨步發展，前端領域的技術方向呈現出了百花齊放的盛況。許多前端學習者在面對如此多元化的技術方向時，不免感到疑惑和茫然。本文旨在探讨近年來前端領域裡一些框架和模式的應用方向及其特點。綜合考慮了客觀規律和主觀判斷的因素，以此為前端人員在技術決策提供科學、合理的分析。
1、前端基石與催化劑
1.1浏覽器的躍進
現在H5已經成為了一個符号，基本上所有具有絢麗界面或者交互的Web界面，無論是PC還是Mobile端，都被稱為基于H5。H5技術的發展以及帶來的一系列前端的變革，都離不開現代浏覽器的發展與以IE為典型代表的老的浏覽器的消逝。
1.2浏覽器端的魔術：AJAX
AJAX即“AsynchronousJavaScriptandXML”（異步的JavaScript與XML技術），指的是一套綜合了多項技術的浏覽器端網頁開發技術，可以基于JavaScript的XmlHttpRequest的用于創建交互性更強的Web應用。AJAX是一種已有技術的mashup，多種技術組合在一起形成了其特色和優勢，早在1998年就已經開始有人使用。Google在地圖和Gmail等産品中對這項技術的深入應用，以及AJAX這個吸引眼球的名字的提出，使其正式站在了聚光燈下，開始吸引無數人的目光。我們知道Web應用中用戶提交表單時就向Web服務器發送一個請求，服務器接收并處理傳來的表單，并返回一個新的網頁。而前後兩個頁面中的往往大部分HTML代碼是一樣的，每次都返回整個頁面内容是一種帶寬資源的浪費。而AJAX應用僅向服務器發送并取回必須的數據，并在客戶端采用JavaScript處理來自服務器響應，更新頁面的局部信息。這樣不僅浏覽器和服務器的數據交換大大減少，而且客戶端也可以更加快速地響應用戶操作。如果你用Gmail就應該知道，Gmail從來都不刷新頁面，所有的請求都是通過AJAX獲取數據進行局部更新。AJAX的出現，以及諸如EXTJS、DOJO等一些前端開發框架的出現，也使得單頁應用（SinglePageApplication）在這個時候流行起來。
1.3ECMAScript
2015年是JavaScript誕生的20周年。同時又是ES6标準落地的一年。ES6是迄今為止ECMAScript标準最大的變革(如果不算上胎死腹中的ES4的話)，帶來了一系列令開發者興奮的新特性。從目前es的進化速度來看，es後面應該會變成一個個的feature發布而不是像以前那樣大版本号的方式，所以現在官方也在推薦ES+年份這種叫法而不是ES+版本。
更讓人興奮的是，JavaScript慢慢不再局限于前端開發中，NodeJs的提出讓人們感受到了利用JavaScript進行全棧開發的能力，從此大大提高了開發的效率（至少不用多學習一門語言）。JavaScript在物聯網中的應用也曾經引起一些追捧與風潮，不過今年物聯網社區更加冷靜地看待着這個問題，但是并不影響各大廠商對于JavaScript的支持，可以參閱《JavaScriptBeyondtheWebin2015》這篇文章。可以預見JavaScript在其他領域将繼續大放異彩，畢竟ECMAScript6，7已經是如此的優秀。
2、模塊化和工程化
2.1前端MVC：Angular/Backbone
這種模式下，前後端的分工非常清晰，前後端的關鍵協作點是Ajax接口，規定好交互接口後，前後端工程師就可以根據約定，分頭開工，開發環境中通過Mock等方式進行測試，同時在特定時間節點進行前後端集成測試。但是，随着業務功能的愈發複雜（看看現在的Gmail），這種模式本質上和JSP時代的Web開發并無本質區别，隻不過是将複雜的業務邏輯從JSP文件轉移到了JavaScript文件中而已。現在，對于一個前端功能、交互複雜的SPA，JavaScript代碼很容易膨脹（超過10萬行）。很自然地，像服務端從JSP向MVC框架轉換的過程一樣，前端開發也出現了大量的MVC框架，比較典型的包括BackboneJS，AngularJS，EmberJS，KnockoutJS。總的來說，MV*框架的提出是為了解決前端開發的複雜度，提供一套規則組織代碼、分層（MVC），通過合理的組織和分層，前端的代碼職責明确、清晰，便于開發與測試。
2.2前端工程化
大部分時候我們談論到工程化這個概念的時候，往往指的是工具化。但是任何一個通向工程化的道路上都不可避免的會走過一段工具化的道路。前端工程化的道路，目标就是希望能用工程化的方法規範構建和維護有效、實用和高質量的軟件。
工程化的要素，會有以下幾個方面：1）統一的開發規範(語法/流程/工程結構)與編譯工具。實際上考慮到浏覽器的差異性，本身我們在編寫前端代碼時，就等于在跨了N個“平台”。在早期沒有編譯工具的時候，我們需要依賴自己去判斷浏覽器版本（當然也可以用jQuery這樣人家封裝好的），然後根據不同的版本寫大量的重複代碼。最簡單的例子，就是CSS的屬性，需要加不同的譬如-o-、-moz-這樣的前綴。而這樣開發時的判斷無疑是浪費時間并且存在了大量的冗餘代碼。
2）模塊化/組件化開發。在一個真正的工程中，我們往往需要進行協作開發，之前往往是按照頁面來劃分，但是會造成大量的重複代碼，并且維護起來會非常麻煩。這裡的模塊化/組件化開發的要素與上面的第一點都是屬于開發需求。
3）統一的組件發布與倉庫。許多程序員在使用Maven前後會有很大的一個對比感，沒有一個統一的中央倉庫與版本管理工具，簡直就是一場災難。這樣也無法促進開發者之間的溝通與交流，會造成大量的重複造輪子的現象。
2.3Webpack
Webpack跟browserify本質上都是modulebundler，差異點在于Webpack提供更強大的loader機制讓其更變得更加靈活。當然，Webpack的流行自然還是離不開背後的react跟facebook。但是從現在HTTP/2标準的應用及實施進展來看，Webpack/browserify這種基于bundle的打包工具也面臨着被曆史車輪碾過的危機，相對的基于moduleloader的jspm反而更具前景。Browserify可以讓你使用類似于node的require()的方式來組織浏覽器端的Javascript代碼，通過預編譯讓前端Javascript可以直接使用NodeNPM安裝的一些庫。相較于Webpack，Browserify具有更悠久的曆史。
Webpack是前端開發真正意義上成為了工程級别，而不再是随意，可以看看這篇文章。筆者第一次看Webpack的時候，沒看懂。當時用Gulp用的正順手，不需要自己往HTML文件裡引入大量的Script文件，還能自動幫你給CSS加前後綴，自動地幫你壓縮，多好啊。不過Grunt和Gulp現在存在的問題就是需要自己去組裝大量的插件，參差不齊的插件質量導緻了大量時間的浪費。并且Gulp/Grunt還并不能稱為一個完整的編譯工具，隻是一個輔助工具。
Webpack還有很令人欣慰的一點，它支持LazyLoadComponent，并且這種懶加載技術是與框架無關的。這樣就避免了開發者在編碼時還需要考慮固定的組件或者代碼分割，畢竟在一個快速疊代的項目中還是很難在一開始就規劃好全部的組件分割。同時，Webpack還支持配合了ReactHotLoader的代碼熱插拔，可以大大地提高代碼的開發效率。
參考文獻：
[1]PatrickCatanzariti，JavaScriptBeyondtheWebin2015，2015.
[2]徐進強，淺談AJAX技術在WEB程序開發中的應用，2015.
[3]寸志，前端模塊化雜談，2015.
[4]阿大、慎裡，前端工程化：雲構建，2016.
[5]chemdemo，基于webpack搭建前端工程，2015.
作者簡介：
占東明，研究生，華東交通大學，講師，研究方向：電子商務與電子政務、互聯網+；
洪家偉，本科，華東交通大學，學生，研究方向：軟件工程；
陳希楊，本科，華東交通大學，學生，研究方向：軟件工程。
徐禮飛，本科，華東交通大學，學生，研究方向：軟件工程；
辛鄢放，本科，華東交通大學，學生，研究方向：軟件工程。