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. 1995: Server-Side Templating. This is the standard templating used in Java’s JSP, Perl’s Mason, PHP, ASP, etc. ie some html code with <?= “language” ?> code embedded in it.
  • 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

  1. Just found you on twitter Michael!

    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.

  2. About Dual-Side Templating (btw. nice word you created): I wrote yesterday about DojoX DTL, a pure javascript client side implementation of the Django Template Language:

    http://www.rsaccon.com/2008/02/django-template-language-dojo.html

    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)

  3. @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.

  4. 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.

  5. 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.

  6. Pingback: Javascript News » Blog Archive » Dual-Side Templating for 2010

  7. 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.

  8. 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/

  9. @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.

  10. Pingback: Is this what the App of 2015 looks like? HTML5 + CoffeeScript + Less + WebStore + PhoneGap + Apparatio

  11. Thanks. With Node, it’s a lot easier – only need one template processor on both sides of the wire.

    We’re also seeing Mustache too these days as a language-agnostic format.

Leave a Reply