[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_11":-5,"_57":58,"_59":60,"_61":62},"routes/user.$name.collections",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":16},"topics",[34],"user",{"_20":21,"_13":14,"_22":23,"_24":14,"_25":26,"_27":28,"_29":30,"_31":16,"_32":33},"loginname","Hkmu","page",1,"limit",20,"total","id","12218","avatar_url","https://avatars.githubusercontent.com/u/3169251?v=3","githubUsername","create_at","2014-04-09T12:38:00.021Z","score",5,"topic_count",0,"reply_count","is_star",false,{"_20":35,"_36":37,"_38":39,"_40":41,"_42":43,"_44":45,"_46":47,"_48":33,"_31":49,"_50":51,"_25":52,"_53":54},"10321","author_id","5747","tab","share","content","废话不多说，先上测试：\r\n\r\n ![all.jpg](//static.cnodejs.org/FoR9jyra_Kx55CfLfZj8DQQUYZJa)\r\n\r\n亲测请访问：【[在线测试地址](http://yangjiepro.github.io/tppl/test/test.htm)】单次结果不一定准确，请多测几次。\r\n\r\n[tppl](https://github.com/yangjiePro/tppl) 的编译渲染速度是著名的 jQuery 作者 John Resig 开发的 [tmpl](http://ejohn.org/blog/javascript-micro-templating/) 的 **43** 倍！与第二名 artTemplate 也有一倍的差距。 \r\n\r\n似乎每一个大公司都选择自己开发模板引擎并将其开源，结果就是社区充斥着数不清的引擎，让人眼花缭乱无从选择。随着时间的流逝，越来越多的功能被添加进去，最终让一个强悍的发动机变成了一台臃肿复杂零件生锈的拖拉机。天呐，我就想网页面里插一段 html，你居然要我往每个js文件里再塞进500行代码！\r\n\r\n不，事情原本应该更简单。保持代码的简洁高效也意味着让生活更加健康愉悦。\r\n\r\n好吧，满脑子装着“封装”或者“模块化”的读者估计有不同的看法。\r\n\r\n下面我们来谈谈如何让引擎更加强劲高效。\r\n\r\n模板引擎分为两大主要阵营：\r\n\r\n1. 原生语法\r\n2. 自定义模板语法\r\n\r\n此两种方案各有各的好，自定义语法相比前者的优点在于，看起来和写起来更加规范简洁，更“像”是一种模板。也能更好的配合编译，并且可以避免用户写出“性能不佳”的代码。部分人认为自定义语法对页面设计人员来说更为友好，这就见仁见智了。而缺点就是通常只能自定义 if else 和 for 循环等简单而有限的逻辑结构，不够强大和灵活。\r\n\r\n自定义语法的优化方法有随着语法的不同而不同，但通常最终都是将其转换为原生的语言逻辑结构。这里主要讨论原生语法模板引擎的优化。\r\n\r\n对于追求性能的模板引擎来说，有两个显而易见的方向：\r\n\r\n1. 编译结果缓存\r\n2. 编译结果静态化\r\n\r\n缓存很好理解，一次编译多次渲染。通常是保存初步正则替换后的字符串中间值，重复渲染时直接拿来使用。\r\n\r\n静态指的是，编译模板字符串生成一个字符串拼接的函数，而不是每次创建函数。渲染操作就相当于一次函数调用，代入变量完成字符串拼接并返回。一般引擎优化到这一步时，渲染方面已经没有太大的差距和进步的空间。大家都成了字符串拼接函数，只能在微小的语法层面做优化。这里说一下，相信从事过前端开发的朋友，都“听说”过一个字符串拼接的“快速方法”：将字符串片段 push 进一个数组，最后再 join 返回，性能比直接采用 + 或者 += 字符串要好。注意，这种方法过时了！在现代浏览器以及Node.js中已经不再成立。通过数组连接字符串只是一个“临时解决方案”，随着各大js编译器的优化和进步，直接采用 + 字符串操作，给了一个编译器在语言底层做出优化的机会，大家还是着眼于未来吧。\r\n\r\n渲染差距不大时，编译则还存在很多“水分”可以挤出来。当然，一部分模板引擎集成了诸如文件加载、Ajax等高级功能，对其性能方面有要求太高似乎也不太合理。\r\n\r\n一般原生语法模板引擎，都采用类似下面的字符串表示：\r\n```\r\n\t\t

<%=title %>

\r\n\t\t<% for(var i in content){ %>\r\n\t\t\t

第<%=i%>段：<%=content[i]%>

\r\n\t\t<%}%>\r\n```\r\n而编译操作就是将这一段字符串转换成类似下面的函数：\r\n```\r\n\t\tfunction(data){\r\n\t\t var str = \"

\"+data.title+\"

\";\r\n\t\t for(var i in data.content){\r\n\t\t\tstr += \"

第\"+i+\"段：\"+data.content[i]+\"

\";\r\n\t\t }\r\n\t\t return str;\r\n\t\t}\r\n```\r\n通常情况都是改变字符串结构，去掉模板标签，再使用 new Function() 创建函数。\r\n\r\n传统传递参数的实现通过遍历数据对象，把对象的名值分离，然后分别把对象成员名称作为new Function的参数名(即变量名)，然后使用函数的appley调用方式传给那些参数。\r\n\r\ntmpl 则使用了javascript不常用的 with 语句实现。实现方式很简洁，省去了var这个关键字。tmpl 性能问题就出在 with 上面。javascript 提供的 with 语句，本意是想用来更快捷的访问对象的属性。不幸的是，with语句在语言中的存在，就严重影响了 javascript 引擎的速度，因为它阻止了变量名的词法作用域绑定。\r\n\r\n而转换的方法有很多种，一部分采用 split() 截断分析，一部分采用全正则替换，更有强悍的引擎使用词法分析，总之各显神通。 \r\n\r\n全正则替换的方案只是一长串的 .replace() 链式调用，看起来代码更加美妙，但由于存在中间过渡状态和方法而导致性能不佳。词法分析更不必说，大量的正则拖慢编译速度。编译优化的重点就在，尽量减少中间态，并减少复杂正则表达式的使用。经过实测，split() 截断分析能减少一部分正则，性能更好。\r\n\r\n[tppl](https://github.com/yangjiePro/tppl) 一开始使用“模板尾标签分割”，即：str.split(\"%>\") 的方式，这与 tmpl 的实现方式不谋而合，上面的字符串被分割为6段，然后为每一段使用一次正则替换：\r\n```\r\n\t\tvar tpls = [\"

<%=title\", \"

\",\"<% for(var i in content){ \", \"

第<%=i\", \"段：<%=content[i]\", \"

<%}\"];\r\n```\r\n\r\n在后来的性能测试中，发现这种实现方式相比其它引擎，并没有太大的提升。看来只能另辟蹊径了。\r\n\r\n经过长时间的冥思苦想，终于发现采用“模板头标签分割”的方式，能大大减少分割结果的数量，但是需要修改模板标签：\r\n```\r\n\t\t

[=:title:]

\r\n\t\t[: for(var i in content){ :]\r\n\t\t

第[=:i:]段：[=:content[i]:]

\r\n\t\t[:}:]\r\n```\r\n方括号 [ 与冒号 : 组成的模板标签相比 <% 能更加清晰的区分html代码与js逻辑代码。通过 .split(\"[:\") 将模板分割为3段：\r\n```\r\n\t\tvar tpls = [\"

[=:title:]

\", \" for(var i in content){ :]

第[=:i:]段：[=:content[i]:]

\", \"}:]\"];\r\n```\r\n如此一来正则替换从6次下降到3次，性能提升将近一倍！而且随着代码逻辑结构的不同，性能提升将会更大。\r\n\r\n关键的正则表达式：\r\n```\r\n\t\tvar line = \"'\"+\"

第[=:i:]段：[=:content[i]:]

\".replace(/\\[\\=\\:(.*?)\\:\\]/g, \"'+$1+'\")+\"'\";\r\n\t\t// '

第'+i+'段：'+content[i]+'

'\r\n```\r\n[tppl](https://github.com/jojoin/tppl) 的源码托管在 Github 上，地址：[https://github.com/jojoin/tppl](https://github.com/jojoin/tppl)\r\n\r\n如果你还有更好编译优化方法，欢迎讨论！","title","全球最快的JS模板引擎","last_reply_at","2018-07-20T06:11:13.589Z","good",true,"top",35,"visit_count",34906,"2014-12-17T02:22:02.351Z","author",{"_13":55,"_22":56},"yangjiePro","https://avatars2.githubusercontent.com/u/2978963?v=4","zones",[107],"tabs",[77,78,79,80,81,82],"publicConfig",{"_63":64,"_65":66,"_67":68},"apiBaseUrl","https://api.cnodejs.org","turnstileSiteKey","","build",{"_69":70,"_71":72,"_73":74,"_75":76},"service","cnode-web","version","0.1.0","commit","9ab83f39eed6b4a14eedbb8fbadfefe40dba3d45","buildTime","2026-07-30T19:01:36Z",{"_20":16,"_84":39,"_86":106,"_88":47,"_89":16,"_91":99},{"_20":103,"_84":104,"_86":105,"_88":47,"_89":103,"_91":99},{"_20":100,"_84":101,"_86":102,"_88":47,"_89":100,"_91":99},{"_20":97,"_84":46,"_86":98,"_88":47,"_89":97,"_91":99},{"_20":93,"_84":94,"_86":95,"_88":33,"_89":96,"_91":92},{"_20":83,"_84":85,"_86":87,"_88":33,"_89":90,"_91":92},10,"key","test","label","测试","visible","sort_order",91,"scope","admin",9,"dev","开发",90,4,"精华","public",3,"job","招聘",2,"ask","问答","分享",{"_20":16,"_108":109,"_110":102,"_111":112,"_113":114,"_88":47,"_89":16},"slug","jobs","name","description","Node.js 招聘信息专区","icon","briefcase"]