Web 模板 Jade、EJS、Handlebars 万行代码解释效率比较,Jade 完败
发布于 2年前 作者 ejialin 18377 次浏览 最后一次编辑是 20天前 来自 分享

在刚刚入门 Node.js,在考虑使用哪个模板时,简单的以1万行数据,进行解释效率比较: Jade 模板:

!!!
html
    head
        title #{title}
        meta(charset="UTF-8")
    body
        div.description #{description}
        ul
            - each data in datas
                li.item(id='item_'+data.index)
                    span= data.time
                    a.art(href=data.url)= data.title

ejs 模板:

<!doctype html>
<html>
<head>
    <meta charset="UTF-8">
    <title><%=title%> - Page Test</title>
</head>
<body>
    <div class="description"><%=description%></div>
    <ul>
<% function data(data) { %>
        <li class="item" id="item_<%=data.index%>"><span><%=data.time%></span><a href="<%=data.url%>" class="art"><%=data.title%></a></li>
<% } %>
<% datas.map(data) %>
    </ul>

</body>
</html>

Handlebars 模板:

<!doctype html>
<html>
<head>
    <meta charset="UTF-8">
    <title>{{title}} - Page Test</title>
</head>
<body>
    <div class="description">{{description}}</div>
    <ul>
{{#datas}}
        <li class="item" id="item_{{index}}"><span>{{time}}</span><a href="{{url}}" class="art">{{title}}</a></li>
{{/datas}}
    </ul>

</body>
</html>

效率比较结果(平均消耗时间,约数) Jade 287ms > ejs 43ms > Handlebars 28ms

Jade 因为采用了类似 zen coding 的语法,比较新奇,但效率极其低下。如果只保留 <li> 部分的1万行数据解释,则约为245ms。 综上所述,对 Jade,我个人不建议,除了效率,另外一个主要原因是可视化太弱,甚至可以说是毫无可视化可言,学习成本高,维护与团队合作成本高,语法过于晦涩、复杂。

最新更新: 根据 @jiyinyiyong 提供的资料,找到 http://jsperf.com/dom-vs-innerhtml-based-templating/413#status 并同样测试了 doT,速度约为15ms,为目前最快,而且提供了相对全面的模板语法:http://olado.github.com/doT/

60 回复

ejs更方便观看,和freemark一样

呼~~,起初是因为jade比较简洁,使用类似zen coding的语法,现在看来放弃jade选择是对的。

干嘛不直接mustache或者hogan

Jade isn’t designed for speed, it’s designed for elegance.

我不同意这句话,zen code对前端的生产过程来说是 elegance,但只是过程,不是结果。

@ejialin Jade 是保持代码的简洁, 我觉得和 Zen Coding 思路大不一样 另外我拿 Jade 当命令行工具用的… 而且我不是程序员,

第一眼瞧见jade就感觉不顺眼

的确, 崇拜缩进的人几乎是跟大半个世界的程序员对着干的…

同感,可视化太弱

jade 同时有空格和tab就会报错,缩进稍微不注意样式全变了,各种undefined着实蛋疼!

很久之前就分享过将目前任意一种模板引擎变成最快的经验:https://github.com/QLeelulu/nTenjin

  • jsTenjin是使用eval来解析的,而nTenjin是使用 new Function 来解析的(速度差别之一)。
  • jsTenjin是使用Array.push来构造字符串的,而nTenjin是使用 String += str 来构造字符串的(速度差别之二)。
  • nTenjin中变量必须由it来指定,例如#{param}要修改为#{it.param},其他和jsTenjin完全一致。

嗯 ,, EJS挺不错,, 感觉比其它灵活一些。。

最近刚用它解析了一个树, 直接定义function, 太方便了。

写了 Slim 就不想写 HTML,正如写了 Sass 就不想写 CSS 一样。

一切都得从需求和应用场景出发,如果你的应用大部分页面的代码都是「万行」以上,而且性能追求极致,那就肯定抛弃 Jade 了,可实际情况呢?

「对jade,我个人不建议,除了效率,另外一个主要原因是可视化太弱,甚至可以说是毫无可视化可言,学习成本高,维护与团队合作成本高,语法过于晦涩、复杂」

「毫无可视化可言」?那是因为你的工作环境导致的吧? 「学习成本高」?顶多半天,绝对能上手。 「维护与团队合作成本高」?额这个,如果你的团队都是写 Jade 的话,何来「合作成本高」之说? 「语法过于晦涩、复杂」?呵呵

所以,上面这句话真的只能是「个人建议」了。

jade上手后开发效率高啊,解析速度慢点以ms为单位关系也不会很大吧?为什么node.js官网会推荐jade,仅仅是因为它的作者是express开发作者?我也是一个jade爱好使用者,对于模板,我只能说,萝卜青菜各有所爱,其他的,谁用谁知道,每个优势都不一样.

一开始我也是觉得jade简直是反人类,一开始用的是ejs,后来用了jade后才发觉是真的好。而且赞同楼上观点,ms级别的性能可以忽略。而且写出一个10000行代码的单模版文件我觉得是有问题的,没有合理的模块化。

@jiyinyiyong 我觉得倒不是缩进的问题 (我就是缩进狂热者), 感觉这东西是不是只能生成 html?

jade 不仅效率差而且相对HTML又多了一种语法,1毫秒的时间足以运行1W个简单函数; NODE的CPU时间是极其宝贵滴,开销在这些方面得不偿失,不喜欢

@neuront 是的. 我想说 HTML 被发明得太过简单, Jade 被设计过度… Jade 是模板引擎, 内嵌数据, 内嵌操作都是有的, 但是太过复杂一般不会去用 我就用来的做静态网页时生成 HTML 用的

写HTML的闭合标签不觉得很烦么?还是大家都用的Dreamweaver?反正用vim写jade感觉起来是比手写HTML欢乐多了……

至于效率什么的……把jade编译成js然后再require进来~应该不比ejs什么的差吧【虽然开发环境下懒得这么做~生产环境这样做可以换回很高的效率吧……

HTML 加了个 <template> 标签, 用 Jade 写模版. 给前端代码调用, 相对会方便点 http://www.html5rocks.com/en/tutorials/webcomponents/template/

并不是说某个模板能有 10000 行, 因为要测效率才搞这么大. 而且模板渲染这种实打实吃 cpu 时间的过程效率不高可能真的会阻塞. 另外谁说 ms 级别性能可以忽略? 一个 GHz 级别的 cpu 一毫秒能执行多少指令!

是在启用缓存的情况下做的测试吗?

我用doT模块写动态html,据说在所有模块引擎中,它的执行效率是最高的。 同时,我用jade写静态html,只因它极度简洁。 现有的html语法简直是反人类的。

ajax加客户端模版,哈哈这效率最高了

在就说过了,jade模版代码有点反人类呵呵

是感觉 jade 模板对服务端开发人员来说有不习惯

同用客户端模板的路过,我这边是socket.io + knockout.js,后端彻底放弃对UI的控制

因为handlebars 兼容了mustache,性能比hogan稍好。handlebars性能好,主要是他有预编译。而ejs这些没有。

反对反对,jade才是正道。上手跟zen code一样舒服。

看这三段代码jade在简洁度上完胜啊

因为开发jsp和php的习惯, 一直在用ejs

@jiyinyiyong

尼玛的为何你不是程序员。。

同意 @ejialin 说的,zencoding 只是优雅在过程,作为结果就不美了。

200 多 ms 还可以忽略!!???怎解!?

jade适合新手,优雅的语法可以快速的进行开发,如果开发的项目真的很需要这种超快的模版引擎的话那么请使用其他的模版引擎,有很多模版引擎是专门为您说的速度效率而生,如:你说的dot,而jade是为了语法优雅而生的,没必要拿两个为了不一样存在目的的东西进行某一方比较,然后说某样东西不建议新手用,而新手往往是为了更快的上手开发,不是吗?另外像@suqian@jiyinyiyong 所说,你想速度快,很简单,用字符串连接或者将jade编译好的模版做缓存. 文章很好,但不要用自己的主观意见做导向…

@alsotang 像该文章说是推荐给新手,那么新手需要为了这ms的速度执着?你认为很有必要,新手需要的是快速上手的模版,优雅的语法以及强大的文档. 如果说这篇文章是为了项目效率推荐给所有noder的话那么还真有这个必要.毕竟所面向的受众群体不一样.因为我认为这篇文章有导向性思维,其实作者的初衷是好的,但是有个人主观意向在里面

@alsotang 去年一月份我还没实习, 我混在社团里天上网翘课…

jade看起来真舒服,要是html一开始就设计成这样该多好,

还是用angularjs 吧。。

jade coffeescript 和python都是很垃圾的东西,不知道为什么有些人就是喜欢这些蛋疼的玩意。

优雅,高于一切…

基本上一个应用(web,mobile 或 desktop)的现实流程是。

创始阶段,几个程序员(通常包含创始人)开发 -> 原型 -> 发布 -> 成功 -> 赚钱 -> 雇程序员 失败 -> 重新开始

在这个流程里,有两拨程序员, 1 创始阶段的程序员 2 赚钱以后雇的程序员

第一类程序员: 考虑的是开发效率,因为要快速迭代,快速出原型,快速响应bug,快速更改需求。 不优先考虑的是程序性能(因为没有多少人用,不存在性能问题),团队合作(一开始团队也没几个人)

第二类程序员: 面临的并不是一个创始过程,而是一个已经成熟的产品。与大量程序员合作。 程序有很多人用,需要提高运行效率, 不断优化。

所以大家在讨论的时候,最好带上研发背景,产品状况。

对于jade的ms级的运行效率慢,如果不考虑产品状况。可真的是永远无法讨论出结果了。

在前端渲染就不需要考虑这种问题了,慢一点快一点都不是问题,现在很多公司前端团队做的不就是这个么,通过异步获取model和模板,再进行渲染,这样需要对SEO进行特殊处理。

很多说jade好的朋友,都忽略了,服务端开发对ui设计都很弱,而一般专业的ui都是直接用html设计, 难道每次ui调整,都要让服务端重新去套一次页面?

对,说jade好的应该都没有参与过真正的团队合作开发

我也插一句,上边很多人说jade对新手来说上手简单,我就是个新手,昨天才看这个东西, 刚刚看文档是突然想到jade这种搞法基本上要将代码全部编译成html,然后觉得会不会效率 低下,所以才来到此帖,作为一个新手,我的感觉是ejs这样的模板更大程度上保留的html的 静态部分,基本上会html就不需要在学太多的东西,而jade感觉不仅要熟知html,还要重新学 一种语法,虽然我大致看了下,也不难。类似软件开发的代码复用性,感觉ejs比jade 的知识 复用性要高,相对来说,学习成本要低一些。

不知楼主在测试时 NODE_ENV 是 development 还是 production ? 据说两种环境下 Jade 性能有显著的不同

没人用dust?

@yakczh 写jade用的啥编辑器?

@leeiio 不过请注意哦,ms只是个单位。举个栗子:1000000ms 和 1000ms

怎样的页面才会用到1w行的数据,比较好奇这个。

个人也更喜欢ejs和swig。

另外,想请教一下,如果熟悉AngularJS的话,理论上是否可以不用Node.js的这些模板引擎?? 如果AngularJS的模板足够强大且好用的话,视图端就直接掌握它就可以了(这应该只是我个人的浅薄想法,目的无非就是想降低学习和适应的成本)。

@iamcc 高并发时,100个请求累加起来应该超过1w行了,10000请求的话,那就会浪费好几秒的CPU时间了

两年前的帖子怎么就被翻出来了 同样对于jade无爱,虽然对于coffeescript还是挺感冒的,总觉得jade的写法实在是反人类

回到顶部