前言
今天突然想吃紅燒肉了，然后問大廚朋友怎么做，大廚哥們見你學藝誠意蠻高，於是扔過來兩本書：
還能好好做朋友嗎?你心里萬馬奔騰，但還沒等吐槽出來，大廚哥們就很專業的分析：肉質是口感的關鍵，醬油是色味的保證，你基礎不牢怎么能做出好的紅燒肉呢?我竟無言以對。
站在前人的肩膀上
HTML、CSS、JavaScript是前端的根基，這是無可否認的事實。正如一輛車當然都是由一堆鋼板和螺釘組成的，但是現在還有人拎着個錘子敲敲打打的造車嗎?李書福說過，“汽車不過是四個輪子加兩個沙發”，去一趟家具城和輪胎店，車不就造出來了嗎?(好吧，我承認誇張系數有點大)
碼農的世界里面經常會提到造輪子，也就是你為了造車而先拿扳手大錘去敲一個車輪出來，然后再用你做出來的車輪你做出來的座椅去組裝成車。這種方式絕對的私人訂制，但是這都是BAT干的事，其他團隊和開發者這么干估計只能造一輛小孩子的玩具車，還是給3歲以下兒童用的這種：
大部分團隊要做的是盡量使用現成的東西組裝，而不是全部自己開發，就像現在網上賣的家具一樣，一套組件寄過來組裝一下就成了一張漂亮的桌子。工程上對於規模較大的產品，必須要用組件化的思維去開發，將項目分解成一個個小組件分給各個小組去開發，各個小組之間相互獨立，最后將所有組件拼成一個完整的成品。而很多小部件其實是通用的，也有很多組織或者個人將自己做好的組件共享出來，直接使用這些現成的組件，顯然是能大大加快開發進度的。
另外，一個顯而易見的事實是，隨着科技的日益進步，終端設備的多樣化、頁面可視化技術的發展，前端技術已經越來越復雜了，再也不是3歲小孩的玩具水平了。比如說用戶交互的增強，比如說終端的多樣化，這些都大大增加了前端開發的復雜度。這個時候從最底層從0開始開發，跟放着現成的打火機不用而去鑽木取火一樣，元謀人都笑了。
一套Web代碼，多平台應用
眾所周知，目前移動設備有安卓、蘋果兩大陣營，而國內微信的恐怖占有率也讓我們不得不開發微信公眾號版本，也就是一個應用至少需要android、iOS、Web App三個版本。3個版本使用完全不同的技術開發，相互之間不能共用代碼，也就是說至少需要3班人馬去開發。當然大家都希望直接用一套代碼跑在3個平台上，具有這個能力的就只有Web App技術了，因為他本質上是一個網頁，而網頁是不分平台的。
但純Web App有兩個問題，一是對硬件的操作能力較弱(原生只有HTML5的一些硬件API)，二是性能比原生差。為了提高對硬件的操作能力，可以使用phoneGap、Titanium這種底層中間件來調用底層硬件，而且可以通過插件的形式擴展，可以說在調用硬件的能力上，這種方式跟原生已經沒什么差異了。這種開發方式與開發Web App無異，目前多數hybrid App都是用這種方式開發的。另一方面，性能方面由於HTML5技術的發展，結合CSS3的話，性能上也有了明顯的提升。這里你可能會說，Web App在安卓版微信上非常容易卡頓呀。這里要科普一下，Web App是通過Web View渲染的，如果Web View的渲染能力不行，就會有明顯的卡頓現象，而安卓微信的Web View用的是10cent的X5內核，國產雖好，仍需努力!作為對比，可以將同樣的Web App放到iOS版微信去看看，性能基本不輸原生，因為iOS版微信用的是與Safari同樣的Web View內核!在谷歌火狐等移動瀏覽器上，性能也相當高，而且隨着技術發展可以預見，在不久的將來Web App和原生App在性能上的差異基本可以忽略了。
前端好熱鬧
因為設備的進化太快、多平台也需要web開發的需求旺盛，所以現在前端變得前所未有的熱鬧。各大互聯網巨頭都推出了自己的前端框架，但框架雖多，核心思想都只有一個：組件化開發。
何為組件化開發呢?搭過積木嗎?組件化就是講一個個頁面功能體做成一個個的積木塊，開發的時候再將各個部分拼接出一個頁面，如下每個框就是一個組件：
一個網站由多個頁面組成，一個頁面由多個組件組成，然后大組件又可以由小組件組成，將小組件拼成大組件，將大組件拼成大組件，再拼成頁面模塊，這就是組件化開發。
So Easy?Too Naive!
這里看到的組件化只是UI表現層的組件化，完整的組件化還包括交互事件、展現樣式、數據交互，也就是說組件擁有自己的屬性、方法以及數據交互能力。比如常見的搜索提示列表，用戶輸入信息傳到服務器上，服務器根據用戶輸入詞查找后將數據返回前端，再由前端展示，效果如下：
常用的UI庫如Bootstrap實現了樣式和動畫的封裝，但是數據交互方面還要自己處理。自己寫也是可以的，服務器將數據返回來，然后前端用字符拼接或者DOM模板技術合成HTML放入網頁中，這一步俗稱渲染。當然渲染可以在前端做，也可以在服務器端完成。簡單的字符串拼接大概是這樣的：
<input type="text" id="" value="紅燒肉" />
<input type="button" id="" value="搜索" />
<ul id="test-ul"> </ul>
<script type="text/javascript">
var temp = '',
list = ['紅燒肉 罐頭', '紅燒肉 調料', '紅燒肉 豬肉', '紅燒肉 包郵'],
listNode = document.getElementById('test-ul');
for (let n = 0, len = list.length; n < len; n++) {
temp +='<li>' + list[n] + '</li>';
}
listNode.innerHTML = temp;
</script>
上面只是示例，實際工程中用的更多的是模板技術，現在模板技術多如牛毛，比如模板的Dust.js、doT.js，MVVM框架級的Angularjs、Knockoutjs等，王婆們都說自己瓜最甜了，選擇困難症患者們你們准備好了嗎?
組件完成之后，還需要一套底層框架來將組件們有機組織起來，根據場景調度出不同的組件來實現需求。這就是路由模塊，以前路由模塊都放在服務器端，現在還需要前端路由來實現單頁應用。在應用比較復雜的情況下，除了需要用路由模塊實現跳轉之外，也還需要根據路由去按需加載每個場景所需的資源，同時保證各個資源的調度不發生沖突，這個資源加載器也算一個框架。
從上面來看，為了實現組件化開發，我們至少要使用幾個框架來組織代碼，如果業務負責彈性較大的話，這樣一套底層架構可不是隨隨便便簡簡單單就能做出來的。而如果自己制作UI的話，那工作量起碼還得翻幾倍，在人員不增的情況下，也就意味着開發周期翻幾倍。想一想現在的互聯網發展速度吧，等你花幾周時間做出一套還算精致的UI，你那原本價值幾百億美刀的idea可能已經被10cent、100du這些公司做了，淚流滿面之際你終於想起了火雲邪神說的：
天下武功，唯快不破。
快，就是互聯網行業的葵花寶典(妹子們放心、程序猿叔叔們都不看第一頁的)。
選擇一個好用的開發環境
為了實現組件化開發，我們一般會用到UI庫、MVVM框架、模塊加載器、項目管理和配置工具等一套東西，這個時候一個好的的開發環境就比較重要了，單純用編輯器敲代碼的刀耕火種時代已經成為歷史了。前端開發環境上，有些公司會用大而全的IDE，有些公司會用各種輕量化的工具組合，這個要看公司技術水平和技術架構的設定。另外，每個公司的開發都會或多或少引入一些現有的框架和類庫，也就是俗稱的輪子。近些年前端空前繁榮，各種框架層(qun)出(mo)不(luan)窮(wu)，如何找到最適合你的項目的框架也不是一件容易的事情。現在前端框架的更新非常快，一個框架火起來到退出人們視野，可能就只有短短兩三年時間。顯然，追隨熱門的風險相當大，特別是一些個人貢獻的框架，因為精力有限，后續的技術支持其實很難保證。要選擇適合公司業務而且穩定的主流的框架技術，這需要有相當的技術積累才能敲定，否則就是帶着開發的小伙伴們去踩坑，等你把坑填好，突然發現這條路已經out了……
在開發工具上，前端界比較火是sublime text(這只是一個編碼器)和webstorm，這兩個定制性很強，換句話說就是你要安裝很多插件或者搭配很多工具才好用，比如好用的編碼插件、調試必備的chrome、精致的UI組件庫、合適的自動化部署工具、順手的測試工具、規范的工程管理插件等等。對於初學者或者技術積累不足的開發人員來說，這些框架/工具的篩選都相當困難，這需要有大牛才可以定技術選型。另外大牛下面的小伙伴們十八種武藝也都要能耍一下才行，因此，對於技術架構並沒那么完整的團隊，這種技術套裝顯然不太明智。
那何不選擇一個大而全的開發環境呢?比如說Eclipse，關於Eclipse就不多介紹了，這里想說的是基於Eclipse開發的WeX5。首先，Wex5是基於Eclipse開發的，而Eclipse無需多言，IBM出品Java開發首選IDE，也就意味着WeX5可以做到前后端無縫結合。另外，WeX5選用的框架都是非常穩定流行的bootstrap、jquery、phonegap，再加上起步的技術支持，再也不用夜深人靜時獨自對着大坑默默流淚了。
組件化方面，WeX5中集成了非常多的Boostrap組件，並使用knockout框架將組件屬性和數據綁定起來，樣式、用戶交互、數據交互這幾方面都完整的封裝好了。數據綁定之后，改動前端的數據會自動反映到數據庫中，數據庫中的數據改動也會自動反映到前端展示，不需要考慮太多數據與表現關聯的實現問題。使用的方法也非常簡單，直接在屬性頁設置即可，管理起來也非常方便。
而且除了組件，WeX5中更有意思的是他提供了很多現成的應用模板，大到一個站點(電商、旅游等業務)，小到比如一個登陸頁這樣的模板，這個真的不要太貼心。我們開發的很多組件都可以從上面直接套用，或者加點小改就可以達到想要的效果，好好利用這些現成的東西，把精力花在業務邏輯上，這才是快速開發的王道啊。
WeX5中的可視化開發
一聽到可視化開發，同學們第一反應就是C#的WinForm界面或者PS中的圖片編輯效果吧，鼠標指哪，效果就去哪。然而，並不是這樣的，前端開發跟桌面軟件開發不同，也就是必須要符合W3C標准。最簡單的例子：你選擇一個按鈕，然后在設計視圖上繪制按鈕，按鈕並不在你鼠標指定的位置出現，而是按照W3C標准文檔流來確定位置。你也不能隨意拖動組件到任意位置，組件的布局和樣式都還是要符合標准文檔流的要求。當然你可以指定絕對定位來脫離文檔流，這樣就可以指定位置了，這些都是符合W3C標准的做法。本質上WeX5只是提供了一個界面來方便地添加組件和修改樣式，並不是可以讓你天馬行空地設計界面的作弊器。你要實現一個布局，其實跟直接在編輯器里面寫代碼一樣，還要要指定定位、浮動、邊距這些，只是WeX5中可以更直觀的實現而已。當然很多同學都想到了Dreamweaver的可視化設計，DW的可視化設計做出來的代碼會有很多垃圾代碼，只能做原型開發用，並不能直接用於線上發布的，而WeX5生成的是符合W3C標准的代碼，這是兩個不同的概念。
WeX5上開發App用的也是調用底層中間件的方式，用的是phoneGap的內核Cordova框架，UI體系則完全基於W3C的HTML5+CSS3+js;引入jQuery和Bootstrap並對移動做了底層優化，效率和性能接近原生應用。所以，用Wex5開發出來的應用可以打包成安卓App或者iOS App，也可以以Web App的形式運行在微信公眾號上，當然PC端也是OK的。回到大家關心的性能和體積上，由於WeX5是以插件的形式調用Cordova框架，UI層上實行按需加載，所以在代碼精簡和性能上都有不錯的表現。