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.
11 responses so far ↓
1 Dave Johnson // Feb 15, 2008 at 5:29 am
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 Roberto // Feb 15, 2008 at 12:19 pm
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 mahemoff // Feb 15, 2008 at 2:41 pm
@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 Nater Kane // Feb 15, 2008 at 3:38 pm
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 Neil Roberts // Feb 15, 2008 at 3:48 pm
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 Benjamin 'balupton' Lupton // Feb 15, 2008 at 5:24 pm
I share the same vision, I’ve made my own post on the subject here talking about current and future applications:
http://www.balupton.com/blogs/dev?title=jaxerthesilver_bullet
Worth checking out is the JSmarty (Client Side Templating):
http://code.google.com/p/jsmarty/
Which is a port of Smarty (Server Side Templating):
http://www.smarty.net/crashcourse.php
7 Javascript News » Blog Archive » Dual-Side Templating for 2010 // Feb 15, 2008 at 8:39 pm
[…] Mahemoff is bullish on templating that runs all over the shop, and explained the progression in his Dual-Side Templating […]
8 Jeff Burrows // Feb 15, 2008 at 9:08 pm
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.
9 pawel // Feb 18, 2008 at 8:38 pm
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/
10 Tom M // Feb 20, 2008 at 12:41 pm
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.
11 mahemoff // Feb 21, 2008 at 12:58 pm
@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.
Leave a Comment