JavaScript Micro-Templating

With all my talk about .NET lately, you probably think that’s all I know.  Well, I’ve been working in .NET so much lately, it’s easy to write about.  I do have many other languages that I love, such as Java, Perl, and my personal favorite JavaScript.

JavaScript holds a special place in my heart.  Specifically, it is one of the first languages that I really got a good grip on, and it’s the one that taught me the most about Object Oriented design.  I remember when I mentioned my background with JavaScript in a .NET meeting when I first started at Ironworks, I saw some cringe.  They were probably frightened of what I thought OO was then.  Obviously, I understand their concerns, but JavaScript is a wonderful and misunderstood language.  It’s eschewing of classical based inheritance for a more prototypical based inheritance system makes it extremely interesting and fun.  Also, it is very expressive as far as languages go, mostly due to its functional nature allowing you to pass around functions as first class objects.  This is all wonderful once you master it and it provides some real awesome capabilities without having a bazillion language features like C#.  JavaScript is a simple language that relies on its functional strengths to model all sorts of interesting constructs, like private variables, various inheritance patterns, closures, currying, and more.  If you have a chance to check out my Stopwatch article, you’ll see the use of private variables through closure in the JavaScript implementation of the Stopwatch class.

Of course, as per the advice of Casey Liss, you always want to keep abreast of advances in the technologies you work with.  With JavaScript, that usually means finding the best practices, and best wheels libraries.  Some individuals out there really lead the work – one in particular is the author of the prolific JS library, jQuery: Jon Resig.  I found an interesting article on his blog about micro-templating in JavaScript.

Basically micro-templating allows a developer to create a re-usable template of markup with embedded placeholders for content.  This separates the JavaScript business logic from the display of data.  Templating is one of those things that I always seem to want to reinvent.  I usually ended up creating what I wanted using the DOM (once creating a templating engine through object literal style notation), but that’s not very conducive to complex HTML structures.  Being able to create the template in mark-up is a huge help when developing those larger reusable structures.  There are many solutions out there from various libraries for templating, but Jon’s implementation was interesting in that it was very small and used the ‘script’ tag in a way I’ve never seen it used:

Code Snippet

1. <script id="template" type="text/html">
2. <div><%=variableName%></div>
3. <a href="<%=href%>"><%=linkText%></a>
4. </script>

Notice the script tag: a ‘type’ of “text/html”.  This of course tells the browser not to evaluate it as JavaScript and allows you to hide your templates in the head rather than the body.  This is a very interesting usage (maybe I’m behind the times, so flame where appropriate), and I really like it.  I really like this, over the solution of putting code in a textarea tag.  In any case, I’m sure his implementation of inserting values into the template is pretty familiar to many of you (reminds me of ASP.NET).  When you make a call to the templating function, you simply specify the ID of the template and an object to evaluate the template with.

I ended up playing with the implementation and found it really cool (see example in the text file).  This is my first foray into this sort of hybrid approach to display templates in JavaScript and I really liked how simple Jon’s example is.

Being out of client side JavaScript for a bit now, I was curious to see what is the flavor of the day out there is right now.  I found a list of templating approaches at MDC and didn’t have time to check them all out.  Any favorite JavaScript templating engines?  Any reason to not dump the template into a script tag with ‘text/html’ type?  I would love to hear other people’s experiences/preferences!

My Skydrive: (or a direct download link – just open it to play and view source to check out)

Comments

[Scott LEwis]

Aaron, I can certainly see the usefulness of JSTemplating. I wonder, though, what are your thoughts with regards to the impact on the document semantics?

[Aaron Romine]

That's a very good question.

Obviously the first impact is that meaning is being transferred from context to client side templates. Loosing that context means your page is less machine readable - and that most of your 'content' lives (presumably) in AJAX calls. This is true however with anything dynamically written. I think the strengths of this approach to templating lies in developing a richer UI more quickly. Providing fallback and accessibility as well as machine accessible semantics is a lot to tackle while maintaining a rich UI.

If your looking at it from a more correctness approach (e.g. using a script tag to hold page mark-up), that is somewhat troublesome. The script tag's type attribute works just like any other mime-type attribute - telling the browser how to process the content's of the tag. The assumption is that a browser won't evaluate a script tag with a 'type' of 'text/html' since it doesn't have a script engine for that mime type. This has desired 'ignore' effect in every major browser I've tried. So from a pragmatic point of view - it works, and is somewhat more elegant than placing them in div's or JS literal strings. That being said it's using the script tag in a way it wasn't meant to be used (at least directly). If you think about it, the content of the tag is still script related, but the original semantics aren't the same. What it accomplishes is a way to have the browser completely ignore the contents of the node. This is extremely helpful when writing templates, as the content of the node may or may not be valid HTML, and mostly definitely isn't desired to be displayed without being evaluated.

Of course this whole approach has it's ups and downs. Most of the templating solutions I've reviewed rely on innerHTML as a setter, which has some major limitations (for instance: tables). I usually resort to using the DOM (slow but it's getting faster and faster). I'll have to look around for some of my old code that used a JSON syntax for creating templates. Not nearly as natural as straight up markup - but much more flexible.

[Scott]

Do you think Jon Resig's solution is production-ready or just a clever experiment? Also, do you see this type of solution becoming obsolete or unnecessary once client-side storage is supported by all of the major browsers?