Single Page Applications have been on the rise over the past couple of years, the most widely known one being gmail. These websites are usually designed for sites that have a large amount of dynamic content which means that it could be sped up by offloading a lot of the functionality to the client side.
SPA’s have been around since before 2005, but when the browses started to support AJAX it become a much easier system to build, another reason for the rise of SPA’s was the rise of smart phones. Because SPA’s are inherently low bandwidth this makes it particularly attractive to developers who are building mobile applications.
Why
The main reason a website goes down the SPA route is twofold: speed up the efficiency and decrease the overall bandwidth of the website. These are all the reasons but are usually the main ones.
Platform Support
Once decided on going down the route of building an SPA you need to decide which platforms it’ll be used on and then which tooling you’ll use in building the system.
Currently there are three different platforms that you build for:
· Browser
· Mobile
· TV & other embedded devices
Most SPA applications either go Browser or Mobile or both with a mix of both with responsive design.
Limitations on each platform:
Browser
The issue if you are going with just or including browsers is that you need to take into the quirks of the different browser versions (typically IE7/8) and what level of functionality they give you. ie – if you choose to include IE7 within your browsers of support you are unable to use localstorage for your SPA. (http://caniuse.com)
Mobile
With mobile development you need to take into account which types of smartphones you’ll be catering to and also which versions of the operating systems you’ll support. This is the main point of why building for mobile can be one of the largest budgets as if you don’t have a Moblie Lab to use this can start to make testing very difficult. If you don’t want to setup a lab there are websites that can do the testing for you (http://www.perfectomobile.com/)
TV & other embedded devices
The last platform which is also one of the biggest is the TV & other devices, these include: Samsung TV’s, PS3, Xbox, SD/HD boxset’s and kiosks. Because of this high range creating a single SPA that caters for all these platforms is impossible, there are some that have a cut-down browser with limited support to a using the standard webkit engine.
If looking into this platform it’s best to split it up to a product range: Samsung TV, Sony TV, PS3 etc…
Tooling
The next step in building an SPA is deciding on the libraries you’ll be using, this is mainly decided on the platform support you are doing, it should also be based on the API’s you have available or that you are building.
If your website will be sending a lot of data upstream (saving data back onto the server) you’ll need one of the pseudo DAL’s that are available (backbone, knockout) which makes pushing data back and forth very easy and integrates into API’s very well.
If the platform you use has a cut-down browser, which usually means that you DOM is not very usable you’ll need to start at the lowest level which can help you develop. Some of these are RequireJS and underscore.
The last part in tooling is the templating engine for displaying the content; some of the old SPA’s used to just display html fragments, but nowadays JSON is the favourite format for the data transport and then use of one of the main templating engines to render the final part. These are mainly being mustache, handlebars, jquery templates and dust.js. (http://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more)
API
The last part in building an SPA is the API, this is the most important part as this is what can really drive how much of the website can be driven by the SPA engine.
These API’s are all REST based and need to cater to the needs of the websites business rules.
Issues
As with most systems there are always trade-offs; with SPA’s the major issue that will cause headaches is SEO, this is because search engines aren’t able to parse a lot of javascript. Because of this most of the content of the website won’t be able to be parsed, unless one of the solutions to this is implemented.
In the next article I will be discussing the main build of the website and what html5 have bought to the table in terms of functionality.
