除非你是BAT,前端開發中最好少造輪子

　　前言

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

　　

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

　　站在前人的肩膀上

　　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層上實行按需加載，因此在代碼精簡和性能上都有不錯的表現。