再談前端HTML模板技術
阿新 • • 發佈:2018-04-20
err 創建 data 函數 size table ora 匹配 區別
在web2.0之前,寫jsp的時候雖然有es和JSTL,但是還是堅持jsp。後面在外包公司為了快速交貨,還是用了php Smart技術。
web2.0後,前端模板技術風行。
代表有如下三大類:
String-based模板技術(基於字符串的parse和compile過程)
DOM-based模板技術(基於Dom的link或compile過程)
Living template (基於字符串的parse 和 基於dom的compile過程)
String-based templating
這是一種基於字符串的模板技術,以字符串和數據為輸入,通過用正則表達式將占位符替換為所需數據的方式,構建出完整的 HTML 字符串。
字符串模板引擎主要依賴一下這幾個dom API:createElement,appendChild,innerHTML。
在這些api中,innerHTML有最佳的可讀性與實用性,成為事實上的主要標準,雖然其他API可能在性能上更勝一籌,但原生js的字符串生成方案中,最常用的還是innerHTML。
基於字符串的模板引擎最大的功勞就是把你從大量的夾帶邏輯的字符串拼接中解放出來了,由於它的完全基於字符串的特性,它擁有一些無可替代的優勢。
It is essentially a way to address the need to populate an HTML view with data in a better way than having to write a big, ugly string concatenation expression.
- 快速的初始化時間: 很多angular的簇擁者在奚落String-based templating似乎遺漏了這一點。
- 同構性: 完全的dom-independent,即可作為用服務器端和瀏覽器端(客官先不要急著搬phantomjs哈).
- 更強大的語法支持:因為它們都是不是自建DSL就是基於JavaScript語法,Parser的靈活性與受限於HTML的Dom-based模板技術不可同日而語
-
安全問題:使用innerHTML 構建 DOM具有安全隱患,用於渲染的動態數據可能存在安全漏洞,如果沒有經過特定的轉義處理,就有可能造成 XSS攻擊或者 CSRF攻擊。
- 性能問題:使用innerHTML 替換 DOM效率較低,即使僅替換 DOM 的一個屬性或文本內容,也必須通過innerHTML 替換整個 DOM,從而導致瀏覽器的重排和重繪。
- 開發效率問題:由於是通過正則表達式匹配後在特定函數中拼接字符串,所以容易造成重復計算,而且完全移除現有的 DOM,再重新渲染一遍,掛載在 DOM 上的事件和狀態都將不復存
- 有可能會創建出意料之外的節點:由於html的parser非常的“友好”, 以至於它接受並不規範的寫法,從而創建出意料之外的結構,而開發者得不到錯誤提示。
- mustache及其衍生handlebar等: 弱邏輯
- Dust.js: 強邏輯 (推薦)
- doT.js: 超級快
- 是活動的: 完成compile之後,data與View仍然保持聯系,即你可以不依賴與手動操作Dom API來更新View
- 是運行時高效的: 可以實現局部更新
- 指令等強大的附屬物幫助我們用聲明式的方式開發APP
- 信息冗余:信息承載於屬性中,這個其實是不必要和冗余的。
- 初始節點獲取問題:通過innerHTML獲取初始節點,沒有獨立的語法解析器或詞法解析器,與 HTML是強依賴關系。初次進入 DOM 的內容是模板,渲染需要時間,所以會造成內容閃動——FOUC(Flash of unstyled content)這個無需多說了,只怪它初次進入dom的內容並不是最終想要的內容。
- 沒有獨立的Parser,必須通過innerHTML(或首屏)獲取初始節點,即它的語法是強依賴與HTML,這也導致它有潛在的安全問題
- AngularJS: 都28000star了還需多說麽
- Knockout: 在此領域內,對Web前端而言是鼻祖級的
- 輕量級, 在Dom中進行讀寫操作是低效的.
- 可重用的.
- 可序列化, 你可以在本地或服務器端預處理這個過程。
- 安全, 因為安全不需要innerHTML幫我們生成初始Dom
- htmlbar: 運行在handlebar之後的二次編譯
- ractivejs: 獨立
- Regularjs獨立
再談前端HTML模板技術