隨著前端領域的發展和社會化分工的需要，繼前端攻城溼之後，又一重要崗位橫空出世——重構攻城溼！所謂的重構攻城溼，他們的一大特點之一，就是精通CSS配置文件的編寫。。。
前端攻城溼跟重構攻城溼是一對好基友，你寫邏輯來，我寫樣式。
好吧，本文並不是介紹重構攻城溼這個職業的，而是通過一個簡單的場景來說說：
【1】在用前端模板之前，我們是腫麼動態創建節點的
【2】為什麼要使用前端模板
一個簡單的場景
下面這張圖片看著應該很眼熟吧？
沒錯，是從mac QQ的好友列表裡面截出來的。
作為一名前端攻城溼，相信不少童鞋的第一反應是：需要用什麼樣的html結構來標識它？樣式要怎麼寫？
好吧，就假設我們可以用下面的dom結構來標識這個“好友”，不考慮其合理性，同時，樣式部分我們華麗麗地直接忽略
大家知道，我們的QQ好友列表是不固定的，於是必須得進行“動態創建”。我們通常會腫麼做呢？
老溼說：createElement神馬的是王道
老溼曾經諄諄教誨我們說，不要通過innerHTML來創建節點，因為那會讓代碼變得混亂不堪。好歹也拿過優秀少先隊員的稱號，當然得聽老溼話了，於是我乖乖地寫下如下代碼：
createElement的問題
筋疲力竭地敲完上面地代碼，我露出了滿足地微笑：老溼你坑我哪！ 就這麼幾個破節點，讓我敲這麼多代碼？
看看上面人肉敲的那坨東西，有沒有發現什麼問題？
自言自語神馬的最討論了，最大的問題在於：dom結構很不直觀，你壓根不知道你創建出來的節點結構是神馬樣子的！！
換別人接手你的代碼，第一件事就是得把上面的代碼跑一遍，然後耐著性子打開控制檯把dom結構翻一遍，才能知道你上面那坨代碼究竟造了個什麼鬼東西出來。好吧，那我改。。。
總結下：費體力，不直觀
那些年，我們一起用過的innerHTML
innerHTML是個好屬性！看看換做innerHTML我們會腫麼做？
哇！只需要幾行代碼就搞定了，麻麻再也不用擔心我加班了！寫代碼，so easy！
一切似乎很美好，但是，慢著！假如我們現在要創建一批節點呢？上面把資料都寫死了不通用啊！
很簡單嘛，把動態變化的那幾個字段提取出來不就得了，如下代碼所示，瞬間高檔大氣上檔次
innerHTML的問題
很好，字符串相加，一堆引號，似乎看出點問題來了。上面的場景算是很簡單的，動態變化的內容不過就頭像、暱稱、個性簽名三個，但現實世界遠比我們預料的要複雜得多。
如果我們想把顯示的好友資料再擴展以下，加上在線狀態、是否會員、是否手機在線，那麼，上面的代碼可能變成這樣（只是yy的）
重構的童鞋拿到他要的東西，心滿意足的就回去寫他的CSS去了，那我們呢？也很簡單，原來拼字符串，現在正則換變量，如下
這裡我們已經隱約看到了前端模板的身影了，結構、樣式與邏輯分離的第一步已經實現了，重構的童鞋根據約定好的HTML模板寫CSS樣式，前端的童鞋負責往模板裡填內容、更新內容，綁定事件，處理用戶交互等，這樣做的好處很明顯：
1. 結構、表現、邏輯分離，便於重構、前端童鞋的分工配合
2. 更好的可維護性，再也不用被一堆createElement，或破碎的字符串之間繞暈了
原來就是這貨：前端模板引擎的本質
看著前面的${avatar}、${nick}等，很多童鞋應該有似曾相似之感。沒錯，這裡用的替換標識，跟jQuery Tmpl的變量替換標識是一樣的.
前端模板引擎的本質，就是變量替換而已。
看到這裡，你是不是覺得：原來這貨就是前端模板引擎啊，不過如此嘛！如果你有這種感覺，那麼：
【1】你以為前端模板引擎有多玄乎啊，本來繞來繞去，最終就是變量替換那麼回事
【2】Too young，to simple，sometimes, too naive. 前端模板引擎做的事情，除了變量替換之外，還要處理邏輯判斷、循環、模板嵌套、預渲染預處理等一堆東東，光有變量替換，實在不好意思說是前端模板引擎。。
好了，之前還有個問題等著解決，找到下面這段代碼
這其實就是邏輯判斷要做的事情，假設用的是jQuery Tmpl，下面這樣寫就可以了
閱讀更多 JS加加網 的文章
