Ever since Smarty rocked my world, I have been on the lookout for template engines in each and every aspect of development. The most recent stumbling block is with JavaScript — HTML formatted strings are ugly but functional while actually creating the elements is just plain horrible. Apparently, client side code is screaming for a template engine, but what is currently available and is any of it practical?
JST - This is as close to Smarty for JavaScript as I could find. The most impressive part is that the templates can be stored in the markup, but processed in the JavaScript. This makes it great for separation.
Ajax Pages - Similar idea to JST, but less powerful. I’m not a fan of the syntax either, but it does the job of a simple template.
Prototype.js Templating - I wasn’t ware that this even existed until recently. I’m not sure of the future development plans for this, but as it stands it is just useful for very basic variable replacement. Examples are provided using strings, but you can just as easily use
innerHTMLsimilar to that of other templating engines.
And there are also individual takes such as ESTE and SXOOP. Actually, Ajax Patterns has a great overview of the area. But more importantly, after researching JavaScript template engines, I began to wonder if they are even worth it? Right now, with no additional code or libraries needed, we have two alternatives:
XSL - We examined 4 Layers of Separation earlier, and came to the conclusion that XSL transformation through JavaScript is feasible, but not desirable. Mainly because of the speed differences and the complexity of XSL. This could change if all browsers had a built in XSL engine.
Hidden Markup - Our current method of choice, just place all of the markup you will ever need on the page, and hide certain portions with CSS. Then show them when necessary. Also provide unique id’s on elements, so that if you need to insert a javascript variable you can access a certain portion of the markup by id.
When it comes down to it, maybe a template engine for JavaScript just isn’t the correct approach because of extra processing time, heftier file size and a learning curve. But it is still hard to pass on all of the benefits of templates. I plan to examine this some more over the next few weeks. If anyone has any experience with a JavaScript template engine on a live site, please do share.
I have personally used JST, in my work while using Ajax on a major project. It involved generating alot of information onscreen, and I knew, for-loops and giant hard-coded strings wouldnt be the answer. I am very happy with the results, but I will definitely look into the other two as well.
I’ve used JST for a major enterprise application. It works well, and delivers very good performance. My app’s AJAX requests can take a while, so I cache them and render and re-render with JST. Lightweight JSON data gets returned by the Ajax request and transformed into HTML on the browser. The Ajax roundtrip to the server takes much longer than rendering, so performance only becomes an issue with very large datasets. It is very similar to Velocity or Smarty, so it was easy to get started. The downside with any JS templating system though is that your template code also needs to get sent down the wire to the browser. This takes a while, and exposes UI logic to the user. Some may prefer not to do this.
Looks like I’ll have some reading to do tomorrow ;)
Thanks, very interesting stuff!
You might be interested in Jack Slocum’s DOMTemplate code, part of his Ext (ex- YUI-Ext) extension library: http://www.jackslocum.com
Hi Ryan,
I’m using Prototype’s Template class to display my latests ma.gnolia bookmarks in the sidebar of my blog.
It works like a charm.
I’m just waiting for ma.gnolia to provide a proper JSON callback to refactor my class before releasing it.
hmm I have used jst, but it too large… i will study Ajax :)
Tobie,
That’s a good example use. Looking at your source, I noticed that you set Magnolia.display in the javascript using a string. Have you considered placing the template in the markup and then in the JS setting Magnolia.display = $(‘magnolia’).innerHTML; ?
Any thoughts on that approach? Or did you do it your way so that the JS file can plug and play anywhere without any dependencies in the markup?
Prototype’s
Templateobject was part of the 1.5 release.Well, that would mean showing some pretty strange content to legacy browsers… But I suppose it would be possible to overcome this, maybe by hiding the content through inline style and showing it with JS.
I’m not sure about the benefits though. What’s your idea behind that question?
I guess the main reason would be for separtion of markup and JavaScript. If you need to edit the markup, you don’t even have to look through a JavaScript file and all of those concatenated strings.
But on your site, your approach makes sense. You’re the only one looking at your code, so you don’t have to separate it out for a designer. I guess I’m more interested on your thoughts on that approach vs the approach that you took.
The main issue I have is that template tokens for these templating libraries are generally incompatible with server-side scripting tokens. Do we really want the designers or developers needing to know two types tokenisation. It would help if there was a standardised format of tokenising or more flexibility in choosing token scheme. I’d personally prefer one which used tags for tokens so they could be viewable in a browser even un-tokenised…
JST looks like it has a lot of potential. I looks easy to implement.
Thanks for the great info!
Hi, there’s this engine that everyone seems to be missing. :-) http://www.naltabyte.se/movie/
And the xml is here.. http://www.naltabyte.se/movie/movie.xml
Note that it’s kinda fast.. up to 8x faster than the ususal javascript execution speed.
I’m using Rails and the prototype Templating engine on a private project. Right now, I hardcoded the html into the js script, but I am going to put it into a seperate file, so that it can be edited on its own. There, I’m using the standard #{yourvar} syntax, so that it might even be reused for rendering a regular partial or action. I get my data as a string via AJAX (to keep things as short as possible), parse it into an array and then into a hash for template processing. Quite a lot of steps, but I’m not sure how best I am going to cache the datasets for later access.
The movie xml thing looks nice, but as with most of the tough AJAX scripting and animation things, it makes my Firefox to jump to the roof with its CPU usage.
Ryan. Here is one more candidate to the list of Javascript template engines. It is called Miro: http://www.devhd.com/labs.htm
One of the benefits of Miro is that template files are pre-compiled into Javascript function. So the solition is very light weight: no library to include and minimized overhead at runtime.
I would be interested in hearing how people think Miro compares with the 3 options you listed.
Cheers, Edwin
We use JST as one of our standard libraries in Zimki for use both in the browser and for server-side templating. Most of the example applications (including the zimki blog, our own company website, etc) use it.
Another new addition is Mjt at http://mjtemplate.org/. This is a offshoot of the Freebase product