前端開發之紅燒肉篇

前言

今天突然想吃紅燒肉了，然後問大廚朋友怎麼做，大廚哥們見你學藝誠意蠻高，於是扔過來兩本書：

還能好好做朋友嗎？你心裡萬馬奔騰，但還沒等吐槽出來，大廚哥們就很專業的分析：肉質是口感的關鍵，醬油是色味的保證，你基礎不牢怎麼能做出好的紅燒肉呢？

站在前人的肩膀上

HTML、CSS、JavaScript是前端的根基，這是無可否認的事實。正如一輛車當然都是由一堆鋼板和螺釘組成的，但是現在還有人拎著個錘子敲敲打打的造車嗎？李書福說過，「汽車不過是四個輪子加兩個沙發」，去一趟家具城和輪胎店，車不就造出來了嗎？（好吧，我承認誇張係數有點大）

碼農的世界裡面經常會提到造輪子，也就是你為了造車而先拿扳手大錘去敲一個車輪出來，然後再用你做出來的車輪你做出來的座椅去組裝成車。這種方式絕對的私人訂製，但是這都是大團隊幹的事，小團隊和獨立開發者這麼幹估計只能造一輛小孩子的玩具車，還是給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放入網頁中，這一步俗稱渲染。當然渲染可以在前端做，也可以在伺服器端完成。簡單的字符串拼接大概是這樣的：

紅燒肉" />

搜索" />

上面只是示例，實際工程中用的更多的是模板技術，現在模板技術多如牛毛，比如模板的Dust.js、doT.js，MVVM框架級的Angularjs、Knockoutjs等，王婆們都說自己瓜最甜了，選擇困難症患者們你們準備好了嗎？

天下武功，唯快不破。

選擇一個好用的開發環境

為了實現組件化開發，我們一般會用到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 AppPC端也是OK的。回到大家關心的性能和體積上，由於WeX5是以插件的形式調用Cordova框架，UI層上實行按需加載，所以在代碼精簡和性能上都有不錯的表現。

WeX5的缺點

任何事物都是兩面性的，一方面WeX5的大而全可以幫助我們搭建一個優秀的開發環境、提供了封裝良好的大量組件，但另一方面加大了平台本身的體積，而且目前由於平台更新較快，相應的技術文檔更新速度跟不上平台更新速度。不過與優點相比，這點缺點還可以接受。還在苦苦尋找好用的組件庫、糾結於各種框架選擇的同學不妨試試WeX5，體驗一把大輪子的快感！