生成静态页面我喜欢 Jade, 但浏览器端模板引擎 Jade 就没有详细的文档来提升了
目前在用的是 Handlebars, Handlebars 是 logic-less 的引擎 有 Sublime Text 支持, 命令行编译工具, 性能也不错 但 logic-less 导致大量逻辑操作要在 helpers 文件里定义 加上有些判断和模板嵌套, 于是感觉整个在 helpers 相关部分变乱, 很想替换掉
看了下 EJS Eco 和 doT
doT 号称性能最快, 可以预编译, 但是文档没有详细给出预编译的命令行工具 命令行有 bug, 更新不长, 没有 Sublime Text 支持, 看得我有些迟疑啊 但基本的 JS 逻辑在 doT 能好恨书写的样子.. 性能当然相当好
EJS 和 Eco 感觉上熟悉一些, JS 逻辑在里边也比较自然, 有 CNode 的 EJS 经验 预编译方面, Eco 有命令行, EJS 是通过暴露 API 提供编译的功能的 Sublime 插件两者都有. 目前基本的担心是性能上会不足, 而我们的前端应用又担心性能
另外一点是 Chrome 插件的 Content Security Policy 会对模板引擎有限制 目前这块更不熟悉, 但 Handlebars 和 Eco 网上有确认没问题的, 等待深入看细节
目前查了很多资料, 但是没有实际操作经验, 也不清楚如何测试,, 哪位同学实际项目中用到过的可以指点一下吗?
参考: WEB模板jade、ejs、handlebars 万行代码解释效率比较，jade完败 Template-Engine-Chooser! jsperf: EJS vs Handlebars jsperf: JavaScript template language shootoff jsperf: performance comparison of jQuery Template vs underscore vs string append vs mustache vs handlebars vs icanhaz vs milk vs swig for table Javascript Templates and Chrome's Content Security Policy sstephenson/eco visionmedia/ejs jonnsl/ejs-compile Javascript Template Engines that work with Chrome's Content Security Policy doT: http://blog.rogerdudler.com/post/29910317444/client-side-templating-with-dot-js http://olado.github.io/doT/tutorial.html#intro http://jsperf.com/dot-vs-handlebars/11 http://olado.github.io/doT/
回复 (17)
用淘宝的juicer
http://juicer.name/docs/docs.html 最近很少碰到 504 的错误啊, 什么情况.. 中文介绍蛮好的.. http://ued.taobao.com/blog/2012/04/juicer-%E4%B8%80%E4%B8%AAjavascript%E6%A8%A1%E6%9D%BF%E5%BC%95%E6%93%8E%E7%9A%84%E5%AE%9E%E7%8E%B0%E5%92%8C%E4%BC%98%E5%8C%96/ 不过编辑器命令行版本,, 哪儿能看?
编辑器命令行版本是什么意思，我一般直接用的
刚看了下他们主页打不开, Github 倒是无压力: https://github.com/PaulGuo/Juicer .. 貌似命令行工具 NPM 找到了,, 但是编译没有详细的文档呀 你说的用是在前端没错吧?
是啊，直接在githup上把juicer-min.js弄下来就可以用了,不需要编译啊
不是. 主要是为了榨性能.. HTML 模板打算在上浏览器跑之前编译到 JS. 这个没讲
@jiyinyiyong 编译模板并根据所给的数据立即渲染出结果.
juicer(tpl, data);会自动编译并缓存的
主页可以访问了,也可以直接编译
@jiyinyiyong 这个可以http://juicer.name/docs/docs_zh_cn.html
swig咋样？ JADE 确实用起来少写很多代码~
.html 后缀, 编辑器支持没问题
语法和文档够清晰 http://paularmstrong.github.io/swig/docs/#tags
性能比 Handlebars 裸跑要好,, http://jsperf.com/swig-vs-handbrake
没找到编译的说明, 不能编译估计性能要掉档次
另外 Chrome 插件上的问题.. 不了解..
Jade 要是能 Handlebars 这么编译也挺想试试
实际上..这个高性能....能体现处在那里..如果一个页面 dom 也就 100 来个节点....我个人觉得....这性能在搞也差不了那里去... 如果是 1000来个节点倒是可以去考虑性能问题..问题是,一次性渲染 1000来个节点的网页..一般来说很少吧?
想想也有道理. 目前我这边遇到这样的,, 某个 View 栏目可能被重复一百条以上 改成非 MVC 的写法, 合并 HTML, 这边的性能问题大概就没有了 可我现在的能力不可能改架构更不可能重写, 于是先注意边角上的性能了 还是觉得你说的有道理..
如果限定于浏览器端，那么性能优先级并不是第一的。与服务器端不同，浏览器端同一时间只需处理单一一个模板，而人类是无法感知50ms级别以下，只要在50ms以内完成一个模板渲染就算达标了，绝大部分的模板实现都能轻松搞定。只要是使用浏览器的是正常人类而不是神马机器爬虫，比50ms更快毫无意义。此时应该优先考虑其他一些因素，例如扩展性、兼容性、学习曲线等等。
另外如果注重用户操作交互性，基于dom的模板要比ejs/handlebars/dot这类基于string替换的模板优胜，毕竟前者只需要替换小量dom树的节点，后者则就算只更新了一个变量，都要重新渲染整个模板。
相关经验不够唉. 从前自己学网页应用, 基本都是 jQuery 风格的 DOM 操作 工作接触到的是 MVC 分离的, 不过交互很多, 部分模块有大量 DOM 操作 我感到手动操作 DOM 有大量的状态需要考虑和维护, 而 MVC 通过刷新减少了状态切换时对多种状态的切换的考虑 我就在想, 为了开发效率能提升能跟上需求, 是不是要尽量避免直接 DOM 操作 现在看这边也是有问题的, 略纠结