Development and UX from Michael Mahemoff. Maker of Player FM. Previously: Google, BT, O'Reilly author. Also thesis papers.

Menu

Dual-Side Templating

Ajax, Ajax Patterns, Javascript, Server-Side Javascript

As server-side Javascript continues to gather momentum, patterns will start to emerge. Dual-side templating, which I’ll explain below, is a pattern I’ve been harping on about for a while because you can kinda sorta use it already with a product like Rails. It will be a lot more powerful with OFL (our favourite language) on both sides of the wire.

The timeline looks like this (with milestone times neatly accelerating towards the singularity :):

c. 2005: Browser-Side Templating. This is an Ajax pattern where you have a block of HTML that includes some custom syntax (e.g. <% ${foo.bar} %>) which are then processed via Javascript.

c. 2010: Dual-Side Templating A single template is used on both browser and server, to render content wherever it’s appropriate – typically the server as the page loads and the browser as the app progresses. For example, blog comments. You output all existing comments from the server, using your server-side template. Then, when the user makes a new comment, you render a preview of it – and the final version – using browser-side templating.

I continue to be bullish on server-side Javascript and am expecting a lot of design patterns to emerge in the next couple years. AppJet and Jaxer are already available, but the real impact will be (a) enterprise-friendly stack, probably Java-based; (b) commodity hosting stack, probably Jaxer based.

16 thoughts on Dual-Side Templating

What about XSLT for client / server templating? Safari has finally caught up and has XSLT in version 3. I guess that would require people to use XML though 😉 That being said, XML to JSON converters are pretty fast.

Combining that with a serverside Django Template Language Implementation seems to me a step in the right direction, especially in the context of a Javascript based web framework (I am actually trying to write such a thing, some parts have been released already, ErlyDTL, ErlyJS, ErlyCairo, ErlyComet, all at googlecode)

@Dave Saw you on twitter :). Haha XSLT dual-side templating will be the catalyst for XML world domination ;). Actually it’s a good point – don’t have to wait for server-side JS as it’s possible to do dual-side with xslt today. I do have reservations about XSLT though, compared to a simple template language.

@roberto Thanks for the link. I hope it does progress in that direction.

I’ve been creating a templating framework that is “duel side” for a few months now in what little extra time i have. returns JSONML for javascript based requests, or full xhtml docs for traditional ones. there’s actually more, but i’m not really ready to talk about it yet.

If you visit my website, it’s actually running dual-side templating using the DojoX DTL implementation that Roberto spoke of above. (The server-generated version is at http://someclosure.com/text/)

And because a language like DTL includes inheritance and other forms of “filling in the blanks” using other templates, arbitrarily complex page mutations can occur.

Your thoughts on using the server to render most of the page is definitely interesting. It would be interesting to write a custom tag for the DTL server-side implementation that worked something along the lines of {% updates %}{% myTags %}{% endUpdates %} that would basically render the content between the two tags, and then duplicate the template code again below it.

But I only can see this type of half-rendering being more efficient the first time the site is visited. For example, when I make return visits to my website, the page loads in a snap because the only data that needs to be loaded is the text of the page.

It would be interesting to look into whether some sort of session-based detection could be done so that their first visit gave them the server-rendered page, but subsequent visits gave them just the raw text.

And one last thought, it would be fairly trivial to take a page that’s been rendered using the server-side version of the language, and once the JS templating is loaded, render it “on top of” the DOM, adopting tags as they match. In this way, you’d be able to have a much more pleasant visual experience (no waiting for JS, no page flicker) as well as having the power of templating.

I don’t think I agree. I have been using ExtJS for almost a year and using lots of client-side templating with dataviews, etc. I don’t know what benefit there is to sometimes doing this on the server (e.g. when the page loads). As client power, and bandwidth are increasing, there is even less reason to worry about this – right? In addition to the convenience of managing all the “templates” in one place, it can be very slick to load the page and then go and get the data to render things.

As a fan of TAL I’m trying to develop JS-based implementation of this template language. My implementation is based on E4X, so it works in Gecko-based browsers (Firefox) and in many server-side JS environments (since most of them is based on Mozilla’s Rhino / Spidermonkey). So it’s not good for client-side usage when you need it to be cross-browser (but in 2010 – who knows?). Here’s the code:
http://code.google.com/p/jstal/

For Perl, try Template Toolkit (http://template-toolkit.org/) with Jemplate (http://www.jemplate.net/) which does exactly this, compiles the templates into Javascript and you can use exactly the same syntax on serverside and clientside. Surprised more people don’t use this.

@Jeff Thanks for reminding me to explain why this is useful in the first place. (a) search-engine optimisation and scrapers (and isn’t that the basis of the semantic web aka “web 3.0”); (b) accessibility – works if JS is off and gives screenreaders initial content (though some screenreaders can deal with dynamic changes to an extent); (c) speed still matters, especially on mobile devices.

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff