Shared Templates

The following is an excerpt, the full tutorial is available in the February issue of net magazine. Once the article is published online I will update this post to contain the full text.

The web has come a long way since the static documents that it was originally associated with. When we think of a ‘modern’ experience on the web, we often think of websites which are responsive, that adapt as we use them and are much more than a static document. These websites are often referred to as “web applications” because they have so much application logic and seem very different when compared to much more static, document centric websites.

Increasingly, the logic that powers these websites is all happening on the front end using JavaScript. Once you start building your website using JavaScript, there’s no need to load any HTML beyond the initial page load. All subsequent requests can be made via AJAX and simply modify the DOM. This type of website is known as a “single page application” or SPA.

This idea of doing everything in JavaScript works well when users have powerful machines and recent browsers that have consistent APIs, but even amongst recent browsers there are major differences in API implementations, and many people are browsing the web on mobile devices with very slow processors. Not to mention people who are browsing the web on a portable device with an intermittent connection who may not manage to download and execute the JavaScript at all.

With SPAs, we also need to ensure the URL is modified as a user navigates the website, so that they can do things like link to a page, use their browsers back and forward buttons, and generally know where they are. Ensuring that a website loads the correct page from a URL is easy when the page is served as HTML, but if your payload is an empty HTML document (as is the case with most SPAs), then your JavaScript needs to put the website back into the correct state. This will likely require additional API requests, and will slow down the loading of the page, not to mention increasing the complexity.

There is another way. We can create a website that loads plain HTML pages, that are then enhanced via JavaScript, and all subsequent navigations using JavaScript, updating the URL using the HistoryAPI AirBnb calls this technique “Isomorphic Javascript” and wrote a blog post about how they are rendering the same views on the server and the client.

In this tutorial, I will show you that it is possible to have your JavaScript-flavoured cake, and eat it too.

We will create a Node express server that uses exactly the same templates as the client to render pages. The templates used in this tutorial are written in Mustache. These templates can be rendered by many server-side languages, including Ruby, Python, Node, PHP and Perl. I chose Node because it means we can write JavaScript on the server and client. Rather than creating our own API, we will be using the Gravatar API. This API requires an email address, and returns a JSON file containing the user’s profile image, assuming they have an account.

You can read the rest of this article in the February issue of net magazine. Once the article is published online I will update this post to contain the full text.

You can see the source code for this tutorial on GitHub.

Notice: Array to string conversion in /var/www/ on line 22

Fatal error: Uncaught Error: Function name must be a string in /var/www/ Stack trace: #0 /var/www/ tags(Object(page)) #1 /var/www/ require('/var/www/joshem...') #2 /var/www/ tpl::loadFile('/var/www/joshem...', Array, true) #3 /var/www/ tpl::load('post', Array, true) #4 /var/www/ site->load() #5 /var/www/ require_once('/var/www/joshem...') #6 {main} thrown in /var/www/ on line 22