jade: a node.js template engine(jade-lang.com)
jade-lang.com
jade: a node.js template engine
http://jade-lang.com/
12 comments
I added a test[1] for Handlebars.js, which is identical to mustache, but pre-compiled. It comes in 2nd in my tests. [2]
[1]: http://jsperf.com/dom-vs-innerhtml-based-templating/47 [2]: http://cl.ly/3002090Y093I383N013r
[1]: http://jsperf.com/dom-vs-innerhtml-based-templating/47 [2]: http://cl.ly/3002090Y093I383N013r
Hm, what about https://github.com/jquery/jquery-tmpl, jquerys official templating plugin?
I use this one with a js-app in conjunction with knockout.js and a few others.
So performance of this one would be interesting, too.
Btw: The actual benchmark is really compelling.
I use this one with a js-app in conjunction with knockout.js and a few others.
So performance of this one would be interesting, too.
Btw: The actual benchmark is really compelling.
JSPerf.com is like a wiki -- so by all means, please edit the page and add a "jquery-tmpl" test.
Yes, i know. I'am just very tired. But anyway, i've added it now.
http://jsperf.com/dom-vs-innerhtml-based-templating/46
It performs really poor..
http://jsperf.com/dom-vs-innerhtml-based-templating/46
It performs really poor..
Oh my goodness -- that's really fascinating. I had no idea that the new jQuery-tmpl templates were that egregiously slow. (Nearly 100x slower, for those who don't want to run the tests.) Thanks for adding 'em to the list.
No problem after all. :)
It's really horrible. But it's not that bad for me. knockout.js does a good job with partial rendering via databinding (ie. only rerender what really changed or is added).
Also it's just beta 1, lets see what happens next.
But adding Eco Template as engine for knockout.js would be a great idea, i think...
Also it's just beta 1, lets see what happens next.
But adding Eco Template as engine for knockout.js would be a great idea, i think...
[deleted]
jquery-tmpl is "Resig Micro-Templates" in his screenshot.
Should be plenty fast enough for all but the most demanding use-cases.
Should be plenty fast enough for all but the most demanding use-cases.
I also got errors with Jade and Eco on Opera 10. The whole page fails with Opera 11, too: http://cl.ly/3s2a0i3V1s422b2Z1Z3C
Pros:
- Clean, nice HAML-like syntax. Expect less typing and easier reading.
- Extensible. It's extremly easy to provide your own filters, doctypes.
- Extremely cool ability to hook the compiler and manipulate the result tree. See CSRF example — it's just awesome.
- Command-line tool to compile templates. A must for static mock-ups.
- High quality code. I'd really wish I could write code as pretty as that.
Cons:
- No template inheritance. And no fragment inclusion (unless you write your own filter or extend the compiler to support some "jade:include" attribute).
- Parsing and rendering is synchronous. So expect Node to block while doing jade.render().
- Filters are synchronous, too. So are iterators (therefore, forget your idea to write model, which lazily fetches data from DB on demand).
- No client-side support. Not like this is important, but this would be neat, considering it's JS after all.
Jade is awesome, but synchronous code in asynchronous world somehow feels wrong.
- Clean, nice HAML-like syntax. Expect less typing and easier reading.
- Extensible. It's extremly easy to provide your own filters, doctypes.
- Extremely cool ability to hook the compiler and manipulate the result tree. See CSRF example — it's just awesome.
- Command-line tool to compile templates. A must for static mock-ups.
- High quality code. I'd really wish I could write code as pretty as that.
Cons:
- No template inheritance. And no fragment inclusion (unless you write your own filter or extend the compiler to support some "jade:include" attribute).
- Parsing and rendering is synchronous. So expect Node to block while doing jade.render().
- Filters are synchronous, too. So are iterators (therefore, forget your idea to write model, which lazily fetches data from DB on demand).
- No client-side support. Not like this is important, but this would be neat, considering it's JS after all.
Jade is awesome, but synchronous code in asynchronous world somehow feels wrong.
Correction: I was wrong on lack of client-side support - it should work, except for IE, which don't support getters.
Yeah, jade pretty much rocks. (I'm a fan of haml too) The nodejs ecosystem is maturing a whole lot.
Express+jade=win:
http://expressjs.com
Express+jade=win:
http://expressjs.com
Do you have any experience with node-router? I'm new to Node.js, and I started using it, but express looks better documented at least. I can't figure out static files with node-router, but there's documentation of how to do it with express.
DailyJS has an excellent tutorial about using Express.js and Jade http://dailyjs.com/tags.html#lmawa
I'm interested as to the anecdotal benefits of using a templating engine like jade or haml. I much prefer the longhand way of embedding code into handcrafted HTML, but then I date back to the early PHP and ASP days and use Django heavily at the moment. Can't quite wrap my head around this mix of generated tags and logic.
With HAML, the big wins for me are:
1) Not making nesting mistakes
2) Less escaping junk(<? ?> or <% %> or whatever)
3) Generally fewer characters to wade through
4) Not having to think about the fact that HTML files are strings... thinking in terms of DOM structure instead.
The things it doesn't handle as well:
1) Micromanaging whitespace between tags (I know, there are solutions, but they're still awkward)
But in truth, HAML kind of reminds me of Rails in that it doesn't actually DO anything you can't do for yourself... but it does change how you think about/structure your code. I'm pretty sure that if I were to go back to writing raw HTML, I would structure/indent it like a HAML document... the same way my non-Rails apps end up looking a lot like Rails now that I've seen how that works.
1) Not making nesting mistakes
2) Less escaping junk(<? ?> or <% %> or whatever)
3) Generally fewer characters to wade through
4) Not having to think about the fact that HTML files are strings... thinking in terms of DOM structure instead.
The things it doesn't handle as well:
1) Micromanaging whitespace between tags (I know, there are solutions, but they're still awkward)
But in truth, HAML kind of reminds me of Rails in that it doesn't actually DO anything you can't do for yourself... but it does change how you think about/structure your code. I'm pretty sure that if I were to go back to writing raw HTML, I would structure/indent it like a HAML document... the same way my non-Rails apps end up looking a lot like Rails now that I've seen how that works.
After doing it the longhand way for over 10 years, I will never go back to that after using Haml. It just feels like the right solution to the problem of dealing with lots of nested markup. It might not be obvious what a benefit it is until you try it. I actually use my own custom-rolled flavor of Haml that is less Ruby-like, and I think it maps a bit better to the stylesheet and javascript.
On the topic of javascript templates, I tried Jaml for a while because I really wanted to have templates that could be cached on the client-side, but the function-based approach was really cumbersome. I ended up creating a server-side pre-processor that converts Haml to vanilla javascript functions that just build the output using string concatenation. These are called at run-time by underscore's template function. Overall, I'm totally happy with it so far.
On the topic of javascript templates, I tried Jaml for a while because I really wanted to have templates that could be cached on the client-side, but the function-based approach was really cumbersome. I ended up creating a server-side pre-processor that converts Haml to vanilla javascript functions that just build the output using string concatenation. These are called at run-time by underscore's template function. Overall, I'm totally happy with it so far.
- faster to write
- less thinking
- easier to modify and understand
I've been writing longhand for 10 years, and it was a no brainer. Just download it and try it on a project for a day. If you are not sold, you can always go back (since it just generates regular html).
I also highly recommend sass over css. The benefits of sass over css is much greater than the benefits of haml over html.
- less thinking
- easier to modify and understand
I've been writing longhand for 10 years, and it was a no brainer. Just download it and try it on a project for a day. If you are not sold, you can always go back (since it just generates regular html).
I also highly recommend sass over css. The benefits of sass over css is much greater than the benefits of haml over html.
I agree about sass.
Haml is Much easier to diff/ merge
Haml is Much easier to diff/ merge
Check out https://github.com/mauricemach/coffeekup too: similarly spare and elegant markup, and nothing but CoffeeScript. (Especially ace if you're using CoffeeScript throughout the stack. And why wouldn't you be?)
jade looks interesting, had not heard of it before and will be looking closely at it for sure.
I'd like to also recommend Nickolay Platonov's little-known but powerful JS templating library "Shotenjin":
https://github.com/SamuraiJack/Shotenjin
Shotenjin is built with Joose v3, which also rocks:
https://github.com/Joose/Joose
I'd like to also recommend Nickolay Platonov's little-known but powerful JS templating library "Shotenjin":
https://github.com/SamuraiJack/Shotenjin
Shotenjin is built with Joose v3, which also rocks:
https://github.com/Joose/Joose
What is the benefit of this style of templating engine compared to for example pure (http://beebole.com/pure/) where you write your html in html, keeping it free from logic and keeping it in a way anyone with html skills can understand?
[deleted]
What are the benefits of using jade over haml-js?
The most important for me is better syntax. This is what haml should have been and I fully expect it to replace haml after it gets ported into other languages. After writing with both, it was an easy choice honestly.
It's also got a couple extra features, but haml could match it.
Read more here: http://tjholowaychuk.com/post/759178288/jade-haml-killer-for...
It's also got a couple extra features, but haml could match it.
Read more here: http://tjholowaychuk.com/post/759178288/jade-haml-killer-for...
I'm curious, too. The syntax looks very similar to HAML but isn't HAML. Wouldn't it make more sense to adopt HAML itself instead of inventing a dialect?
Haml-js is nearly ten times faster, for what its worth...
The page is really pretty looking and simple. :)
Very nice.
Very nice.
http://jsperf.com/dom-vs-innerhtml-based-templating/45
Here's a screenshot of the results: http://cl.ly/42CP
It can make a difference, because UI-rendering can often be the performance bottleneck in a JS web app ... especially in older browsers like Internet Explorer.
Although, perhaps it isn't a problem at all -- looking at the source, it doesn't appear as though Jade supports IE:
https://github.com/visionmedia/jade/blob/master/lib/jade.js#...