Recommended JavaScript HTML template library for JQuery?

Question

Any suggestions on which HTML template library would go well with JQuery? Googling turns up quite a number of libraries but I'm not sure whether there is a well recognized library that would stand the test of time. Thanks in advance.

Answer 1

There is a reasonable discussion document on this topic here, which covers a range of templating tools. Not specific to jQuery, though.

Answer 2

jTemplates

Answer 3

I finally ended up developing my own.

If you are using Script# you may want to consider SharpTemplate, a strongly typed, super efficient HTML templating engine.

Answer 4

http://code.google.com/closure/templates/docs/helloworld_js.html Look at my answer at http://stackoverflow.com/questions/3585573/html-templates-in-javascript-without-coding-in-the-page/3586581#3586581

Answer 5

A couple years ago i built IBDOM: http://ibdom.sf.net/ | As of december 2009, it supports jQuery binding if you get it straight from the trunk.

$("#foo").injectWith(collectionOfJavaScriptObjects); or $("#foo").injectWith(simpleJavaScriptObject);

Also, you can now put all the "data:propName" markers in class="data:propName other classnames" attributes, so you don't have to litter your application's content with those markers.

I've yet to update a bunch of the documentation on there to reflect my recent enhancements, but the i've had various versions of this framework in production since 2007.

To skeptics of this question:

Back when Microsoft invented with IE5 what we now know as XmlHttpRequest and the "ajax" pattern, part of the promise behind this was to purely exchange data between a web browser and the server. That data was to be encapsulated in XML, because in 1999/2000, XML was simply just so very hot. Beyond retrieving an xml document over the network with a call-back mechanism, MS's MSXML ActiveX component also supported a pre-draft implementation of what we now know as XSL-T and XPath.

Combining retrieving HTTP/XML, XPath, and XSL-T, afforded developers tremendous creativity to build rich "documents" which behaved as "applications", purely sending, and more importantly, retrieving data from the server.

Why is this a useful pattern? It depends on how complex your user interface is, and how much you care about its maintainability.

When building a visually very rich semantically marked-up interface with advanced CSS, the last thing you want to do is chunk-out pieces of markup into "mini-controller/views", just so you can .innerHTML a document fragment into the main document, and here's why.

One key tenet of keeping an advanced html/css user interface manageable, is to preserve its validation at least during its active phase of development. If your markup validates, you can focus on your CSS bugs. Now, if fragments of markup end-up getting injected during various stages of user-interaction, it all becomes very unwieldy to manage, and the whole thing gets brittle.

The idea was to have all of your markup UI constructs in a single document, retrieve ONLY DATA over the network, and use a solid framework which will at the very least simply inject your data into your markup constructs, and at the most replicate markup constructs which you flagged as repeatable.

This was possible with XSL-T and XPath in IE5+, but virtually no other browsers. Some F/OSS browser frameworks have been dabbling with XPath but it's not quite something we can rely on just yet.

So what's the next best thing to achieve such pattern? IBDOM. Get data from your server, inject it in your document. effortlessly.