Myself and fellow MVPs Alex Klok, Angel Puntero and Mihai Cadariu came up with an open source framework for Client-side templating during the recent MVP retreat in Portugal. Apart from giving us the chance to mess around with some fairly new technology I like to think that we were putting some solid thought into an area that I expect to see more and more traction in Tridion implementations in the coming couple of years. 

This post talks through my thoughts on why you might want to execute templates in the browser, and describes the elements we pulled together for our framework.

Its already out there, and has been for a while…

The only surprising thing about doing templating in the browser is that its not happening more often already on Tridion implementations. The technology has reached a decent level of maturity – witness the number of Javascript templating frameworks available, many of them spin-offs of browser GUI work by heavyweights like Google and Twitter. Most high-volume sites that weave content and applications together with visitor-centric personlization/targetting are using this approach in some form or another – LinkedIn being a notable example that we probably all use.

Advantages – Performance and Caching

My original thoughts on working with client-side rendering came from projects where we were looking into the integration of Content Delivery Networks. The problem was that richer websites often contain an element of content personalization or targeting, and not just on particular pages hidden away in the depths of the site, but on the home page, or campaign landing pages – exactly the pages a truely global company would benefit from caching with their CDN. As most CDNs cache a ‘static’ copy of the page (just the HTML) and do not execute server-side code (where traditionally the personalization or targetting logic would execute), the only solution is to have the dynamic bits rendered in the browser – hence the need for some client side templating. We would bake or fry the static content into the page served to the browser (which would also be the content cached by the CDN), and then make AJAX calls back to a content service to deliver dynamic content. 

Free your Content

Freeing your data from the web page by making it available through web services in a data format like JSON or XML is also not a new idea, but again, there are surprisingly few Tridion implementations that take this approach to their content. The rapid move away from desktop browsers to mobile web and apps as the main internet touch point has induced panic in many a company. Most people have an opinion, but who knows exactly what the future holds? One thing is for sure, if you free your content from the web page, then you are in a better position to adapt to rapidly changing and evolving content delivery challenges.

Harness local browser resources

I read recently that the spacecraft Voyager 1 has left the solar system. This was launched in the 1970s and has 240,000 times less memory than an iPhone. Client side templating is not rocket science, so the majority of user’s devices can handle the extra load that you are putting on it. And of course, the benefit is that this is processing you are saving yourselves on your own servers, meaning you can lower your costs and/or increase your potential load.

How do we do it for Tridion?

Like any good solution, we decided to develop as little as possible ourselves, and reuse stuff that’s already out there, purpose built for the kinds of things we were trying to use. Our shopping list was thus:

1. A Javascript templating framework that would enable us to do operations familiar to a typical template developer (loops, conditionals and easily access a full content data model)
2. A webservice that we could make AJAX requests to, to get Tridion published content
3. A client proxy for the webservice, to avoid having to write any code to convert our AJAX requests into objects

There was some debate for the first item, Angular and Knockout were both mentioned. Angular is richer. Knockout simpler to use. In the end we decided to use Angular (mainly as Alex was already a guru at this), but develop our framework as independent from the template technology as possible, so it should be possible to swap in other technologies without too much work. 

The second also caused debate, the two options being to roll our own webservice as a wrapper around the broker API, or to use the Tridion oData Content Delivery service. Remembering that we didnt have much time, we plumped for the Tridion oData service.

This choice then guided us to the third item, where we were in luck to discover a relatively new project: Jaydata. This does a lot more than we needed, but the key thing was that it had all the code to handle oData requests, and there was even a method of generating the proxy objects, so we could start coding straightaway with JS objects like ComponentPresentation.

Using a simple TBB to publish components as JSON to the broker database, we then simply sewed all the elements together…

Well actually of course it wasn’t quite as simple as that, we did face a few obstacles, the subject of which will form some coming-soon blog-posts from the project team. Alex has already blogged his introduction, which contains some further insights on why client side templating is worth looking into, and as he mentioned – if you are interested in trying out, or have done something like this yourself already – get in touch!

Thanks to the Keep Calm-O-Matic for the image