关于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应用中占主导地位。而且面向架构的服务,移动端的广泛使用,前端模拟引擎是确实越来越重要

 

转载于:https://my.oschina.net/xiandafu/blog/746593

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
async和await是JavaScript中的一种异步编程方式,但是很多人在使用时会存在一些误区。下面详细介绍几个常见的误区。 1. async函数一定会返回Promise对象 这个说法是错误的。虽然async函数默认会返回一个Promise对象,但是如果async函数里没有使用await关键字或者手动返回其他类型的值时,async函数会直接返回对应类型的值。 2. await只能在async函数中使用 这个说法也是错误的。虽然await主要用于等待Promise对象的resolve或reject操作,但是它也可以在任何返回Promise对象的函数中使用。 3. await后必须跟着Promise对象 这个说法也是错误的。虽然await关键字通常用于等待Promise对象,但是它也可以等待任何返回值的操作,只要返回的值不是Promise对象。例如: ``` async function test() { const result = await 1 + 1; console.log(result); } test(); // 2 ``` 4. async函数和普通函数写法没有差别 这个说法是错误的。async函数和普通函数虽然看起来很像,但是它们之间有很大的区别。async函数异步执行,而且默认会返回Promise对象,可以使用await等待异步操作的结果。普通函数是同步执行的,没有默认的返回值。 5. 多个await会依次执行 这个说法也是错误的。虽然await关键字用于等待异步操作,但是它并不会使得整个async函数变成同步执行,多个await操作并不会依次执行,而是并发执行。 总之,async和await是JavaScript中非常实用的异步编程方式,但是在使用时需要注意清楚它们的特点和注意事项,不要陷入误区

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值