關於beetl認識的幾個誤解

   beetl 現在國內越來越流行，社區網站每日訪問量都有上千，下載量每日保持在20個左右（無法統計maven的）。 qq群在滿員之前已經踢走了一撥又一撥的不活躍會員還有少量價值觀不符合的人（寫這篇文章的時候正是阿里月餅事件發酵）。名氣大起來了，負面評論也多。我列出了一些負面評論誤解

Beetl缺少文檔

如果搜尋beetl教學和文檔，你會發現基本上只能定位到beetl官網文檔和作者寫的少量beetl使用說明，不能認為beetl用戶少才導致的。這恰恰說明了beetl官網文檔寫的夠用，且社區提供了各種demo以及及時的問題回答。相比較JSP，Freemaker那種連一個循環如何使用都有無數文章，無數作者孜孜不倦的對這些簡單概念寫文章說明。 Beetl確實沒有這樣的文章，甚至也沒有影片。 Beetl文法上基於了JS，而且本來就是國人研發的，文檔，交流都沒有什麼困難

 

Beetl使用了 , 像jsp，非常難看。

這也是誤區，事實上，beetl定界符可以允許任意符號，例如類似PHP的  ?> ,類似html註釋的,或者簡單的@和回車換行符號配對，如下程式碼

@ for(u in userList){
<span>${uLP.index}:
${u.name}</span>@}

Beetl的語法像Java

 Beetl語法參考了javascript，因此，從形式上看確實像Java，這也是Beetl學習曲線低的原因。但Beetl作為一個模板語言，專門用於輸出，比基於Java的JSP好很多，比如上一段代碼，uLP是一個內置的循環變量，可以獲得當前索引，奇偶行等信息，只需要在循環變量後加上LP就可以了，這就是專門針對模板輸出用的。另外，beetl支援elsefor，如上程式碼，沒有進入循環體，可以使用elsefor做說明

@for(){

@}elsefor{
<span> 无记录 </span>
@}

Beetl 模板語言為模板定制的特性還有如下：

省略的三元表達式

安全輸出

select- case 語法

html 標籤

格式化輸出

直接呼叫java方法或屬性

多種佈局函數

模板變數

嚴格MVC控制

模板變數

嚴格MVC控制

倆回事情

更喜歡指令式，而非腳本式模板語言。

類Velocity這樣的指令式模板語法有人更喜歡，原因是指令少。但缺點也明顯，再應付複雜的邏輯渲染的時候，往往更難看、難易書寫。 beetl是腳本式的模板引擎，語法可能相對較多，但基於JS，並不難理解，腳本式的語法在應對複雜渲染邏輯的時候也更得心應手點。 不要被指令式模板引擎的 helloworld範例所迷惑，看起來爽，但用在專案裡，最後跟腳本式是一樣的。

 

模板效能不重要

  也在網路上看到認為與其最佳化模板引擎，不如優化資料庫存取這麼一說，我覺得說的是對的，如果我也會先考慮優化資料庫存取等地方，但如果這些都優化好了，也可以在用更好的模板引擎提升行性能 ，beetl性能6倍於freemaker，2倍於JSP（也有三方測試3倍於JSP，可能是JSP是用了過多JSTL導致的），模板引擎涉及CPU運算，以及IO輸出，其實是在Web應用中，較為消耗資源的一塊。我以為，如果能降低這塊消耗，對系統效能提升還是有效果的。如果你的資料庫存取已經優化的很好，業務代碼已經寫的很完美，為什麼不能使用性能更好的模板引擎呢，beetl又不需要做什麼額外的操作才能達到性能極致，他本來就有很好的性能。

 

後端模板引擎不重要了

這個是事實，現在前端模板引擎越來越重要，beetl 也開發了一個beetljs，但因為體積龐大，相比那些7K，8K的模板引擎，實在拿不出手，所以一直沒有推出。只能日後優化體積，縮減語法特性再選擇時機推出。

就算趨勢如此，但我認為後端模板引擎還是有其優點的，目前還是很重要：

後端模板引擎功能，可維護性等遠遠強於前端模板引擎

🎜後端模板引擎位於後端，因此獲取後端數據得心應手，而前端模板引擎需要準備所有數據🎜🎜後端模板引擎應用範圍廣：還有代碼生成，靜態頁面生成，後端的一些模板功能，如發送郵件，短信等🎜

在大部分公司前端人才缺乏，使用前端模板引擎會導致更多的人集中到前端。公司在沒有準備好這項變更前盡量少使用前端模擬板引擎

開發效率來講，後端模板引擎流行多年，因此，應該比前端模板引擎開發效率更高

後端模板引擎適合SEO優化，前端模板引擎則很難

後端模板引擎有佈局功能

我覺得當前使用模板引擎的正確姿勢是前端+後端結合使用，當然前端模板引擎現在也在藉鑑後端模擬引擎功能，會越來越完美,   說不定哪天真的會在web應用中占主導地位。而且面向架構的服務，行動端的廣泛使用，前端模擬引擎是確實越來越重要