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:
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...
- 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.
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.
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.
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.
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.
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?)
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?
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.
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?
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#...