Backbone Reactive – Fallback Version

This is Part One of the Backbone Reactive Tutorial. For all sections, please view the Table of Contents.

The first thing we should always do, when building any application that relies heavily on the frontend Javascript is to produce a fallback version. The reasons are pretty straight forward:

  1. If a user visits your application and for whatever reason they don’t happen to Javascript enabled, then they will still be able to get some value out of your site. This will obviously be heavily reduced value, but it is better than nothing, of even worse, a message saying “You Need Javascript”
  2. It is always handy for SEO purposes to have at least some content on the page, not just a link to a Javascript file which will generate the content.

So given that we need some fallback content, when should this be produced? Personally, I prefer creating a static site right at the beginning of the process, and then layering the Javascript functionality over the top. For me it makes sense as the likely hood that I’ll retroactively fit the fallback content underneath the Javascript is pretty slim.

In this initial commit, all I have done is to create the static html fallback site. It includes two main pages – the homepage and a message list page, as well as 5 messages. In a real application these would most likely not be static pages, but instead generated via PHP, Ruby, NodeJS etc. However, for the purposes of this project, I am not at all interested in the backend.

Included in this initial commit is a very simple static web server (powered by NodeJS) to serve the files. This has been included so you don’t have to worry about setting up Apache or similar. Instructions for use are in the _server.js file itself.

You can find the source code of this initial commit in the Git Repo and under the tag ch1-fallback.

Next time we’ll look at building a simple Backbone.js application over the top of our fallback setup.