关于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控制

这些语法都是模板特供的语法，完全跟java是俩回事情

更喜欢指令式，而非脚本式模板语言。

类Velocity这样的指令式模板语法有人更喜欢，原因是指令少。但是缺点也明显，再应对复杂的逻辑渲染的时候，往往更难看和难易书写。beetl是脚本式的模板引擎，语法可能相对较多，但基于JS，并不难理解，脚本式的语法在应对复杂渲染逻辑的时候也更得心应手点。 不要被指令式模板引擎的 helloworld例子所迷惑，看起来爽，但用在项目里，最后跟脚本式是一样的。

 

模板性能不重要

  也在网上见到过认为与其优化模板引擎，还不如优化数据库访问这么一说，我觉得说的是对的，要是我也会先考虑优化数据库访问等地方，但如果这些都优化好了，也可以在用更好的模板引擎提升行性能  ，beetl性能6倍于freemaker，2倍于JSP（也有三方测试3倍于JSP，可能是JSP是用了过多JSTL导致的），模板引擎涉及CPU计算，以及IO输出，其实是在Web应用中，较为消耗资源的一块。我以为，如果能降低这块消耗，对系统性能提升还是有效果的。如果你的数据库访问已经优化的很好，业务代码已经写的很完美，为什么不能使用性能更好的模板引擎呢，beetl又不需要做什么额外的操作才能达到性能极致，他本来就有很好的性能。

 

后端模板引擎不重要了

这个是事实，现在前端模板引擎越来越重要，beetl 也开发了一个beetljs，但因为体积庞大，相比那些7K，8K的模板引擎，实在拿不出手，所以一直没有推出。只能以后再优化体积，缩减语法特性再选择时机推出。

就算趋势如此，但我认为后端模板引擎还是有其优点的，目前还是很重要：

后端模板引擎功能，可维护性等远远强于前端模板引擎

后端模板引擎位于后端，因此获取后端数据得心应手，而前端模板引擎需要准备所有数据

后端模板引擎应用范围广：还有代码生成，静态页面生成，后端的一些模板功能，如发送邮件，短信等

在大部分公司前端人才缺乏，使用前端模板引擎会导致更多的人集中到前端。公司在没有准备好这一变化前尽量少使用前端模拟板引擎

开发效率来讲，后端模板引擎流行多年，因此，应该比前端模板引擎开发效率更高

后端模板引擎适合SEO优化，前端模板引擎则很难

后端模板引擎有布局功能

我觉得当前使用模板引擎的正确姿势是前端+后端结合使用，当然前端模板引擎现在也在借鉴后端模拟引擎功能，会越来越完美,   说不定哪天真的会在web应用中占主导地位。而且面向架构的服务，移动端的广泛使用，前端模拟引擎是确实越来越重要