Friday, February 15th, 2008

Dual-Side Templating for 2010

Category: JavaScript

Michael Mahemoff is bullish on templating that runs all over the shop, and explained the progression in his Dual-Side Templating piece:

  • 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. <% ${} %>) 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.

Posted by Dion Almaer at 5:58 am

2.7 rating from 23 votes


Comments feed TrackBack URI

Am I missing something something or isn’t dual side templating happening already? Isn’t this exactly what frameworks like lowpro and scriptaculous help achieve (and in rails, integrating with RJS)?

I think a 2010 estimate for something that is already in production use is anything but bullish.

Comment by rubypond — February 15, 2008

me thinks Ajaxer too!

Comment by fighne — February 15, 2008

Steve Yen experiments with creating the same template for both server and client with his TrimJunction framework.

Comment by moschel — February 15, 2008

The future is now.

Comment by Mathieu \'p01\' Henri — February 15, 2008

@rubypond I don’t get how lowpro/scriptaculous do templating or am *I* missing something…in this article, I’m talking about templating like PHP/JSP tags.

@moschel Thanks for pointing it out. It makes sense; Steve Yen’s trimpath was one of the very early JS templating languages and given that it’s incorporating server-side JS, I could see it.

Comment by Michael Mahemoff — February 15, 2008

Server-side JavaScript seems like the only reasonable way to achieve this, even having the same API in two code bases isn’t great. On the other hand, the Ruby on Rails approach of returning HTML snippets isn’t a bad one… you need to save the comment on the blog post anyhow.

Comment by nathany — February 15, 2008

I share the same vision, I’ve made my own post on the subject here talking about current and future applications:
Worth checking out is the JSmarty (Client Side Templating):
Which is a port of Smarty (Server Side Templating):

Comment by balupton — February 15, 2008

Posted on the article (but still awaiting moderation):

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

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.

Comment by pottedmeat — February 15, 2008

Why not use with XML/XSLT? It’s web standard technologies and a reality right now using Sarissa.js on A-grade browsers. We use this all the time and really gives us clean separation of concerns as well as nice modular HTML.

Also I believe FREJA comes with some sort of fallback server-side XSLT processing for PHP as well.

I don’t really understand why this technique isn’t more prevalent…

Comment by mundizzle — February 15, 2008

The future is definitely now!
I’m using a single template on both the server and client side to create content boxes for user upload-able content. The server passes the template as a hidden div for use on the client side after using it to render any content previously saved during the session.
This is an awesome technique and works very well.

Comment by jqs — February 15, 2008

What’s with the “Secure string interpolation” from Google. Won`t it fit the needs for templating in javascript

Comment by CiDS — February 16, 2008

c. 1998: Rhino
c. 1999: XSLT

We need to come up with a name for the common Ajax pattern in which developers have been doing something for a long time, and then someone gives it a name and writes an article about it.

Comment by trav1m — February 16, 2008

Leave a comment

You must be logged in to post a comment.