Are SPAs (Single Page Applications) suitable for sites aimed for mobiles?

Question

I am planning to create a website with around different 20 views/pages primary for mobile phones.

If I want to focus on a making the user experience very responsive (as

Answer 1

There are two big ways in which going the SPA route gives you opportunities you can take advantage of to improve user experience:

Less downloaded content

If you have different HTML pages for each page in your application, you will have to download each of them in their entirety. If your site shares common markup between the pages, it will be re-downloaded for each page. Compare this with an SPA where at the very least you download only the changes needed to go from the current page to the next one. In some cases there will be little improvement, in others it will be quite significant.

Another way in which SPA can be more efficient is if you separate the logic of building the markup and your data. Consider the example of having a list with 100 names and scores:

Traditional:

<ul id="myList">
  <li><strong>Name 1</strong> score 1</li>
  <li><strong>Name 2</strong> score 2</li>
  <li><strong>Name 3</strong> score 3</li>
  ...
  <li><strong>Name 100</strong> score 100</li>
<ul>

SPA:

<ul id="myList"></ul>

var myData = { 
  "Name 1" : "score 1",
  "Name 2" : "score 2",
  "Name 3" : "score 3",
  ...  
  "Name 100" : "score 100"
}
var html = '';
for (var name in myData) {
  var html += '<li><strong>' + name + '</strong> ' + myData[name] + '</li>';
}
document.getElementById('myList').innerHTML = html;

The SPA model can save bytes even when building the DOM. Also, the logic is reusable, so if you need to re-build the list with more content, you only need to add stuff to an object and call a method.

Striking the pefect balance between download size and processing required is a very difficult problem and it depends on many issues, including the particularities of the application, the device, other tricks that can be done, etc. Fortunately a common sense approach gives good enough results most of the time.

Transitions

Other than some IE experiments you can't make any change to transitions between different pages in the browser. This is an important selling point for SPA because with clever transitions you can give the appearance of speed even when the site is not that fast. Even without transitions, an SPA is much better suited to give feedback to the user while loading than a regular site.

One thing to note is that you should focus on the initial page load to be as smooth as possible (by only loading the bare minimum) and after that batch requests as much as possible. A big problem with mobile latency is that if the device doesn't need to use the radio for a while, it will be turned off. Turning it back on again incurs a significant overhead, so requests should be batched whenever possible.

---

My personal advice is that if you can go SPA, you should. There is very little that can be done to improve efficiency for regular HTML sites, while i suspect SPAs will continue to be improved constantly in the future. At the very least, you can expect similar performance from a carefully built SPA as you get with regular HTML and the potential opportunities can give big rewards.

Answer 2

TL;DR: single page applications require more attention to their architecture, especially if you're migrating functionality of an existing website (d'oh, brownfield projects are tough).

A common pro-SPA argument focuses on less downloaded content. While technically correct, it holds less relevance on a cellular connection with high latency. Spoiler alert: all cellular connections are high latency.

• The difference between downloading 10KB and 15KB is negligible, it's the connection establishment overhead that drains all joy from a mobile experience.

• You can rarely influence latency (although using a CDN and hosting in the cloud can), but you can offset its impact. Resource bundling and minification is effective, and the underlying concepts are applicable regardless of the environment used.

• You should be gzipping your content anyway, and the way it works further deflates (haha) the size argument. Basically it focuses on repeating character sequences and is more efficient for things like bloated HTML markup rather than lean JSON. This gets ridiculous for clojure-compiled javascript.

• Always a good tip, but make sure that your content is served with valid Content-Length headers to allow persistent connections.

On the other hand, a common anti-SPA argument goes like this: ZOMG so much javascript. Sure, you can no longer afford to have memory leaks like you "can" on a traditional website (most are remedied as soon as a different page is navigated to), but write good javascript and you will be rewarded.

• Using jQuery on a mobile site is sometimes a necessary evil. Might as well use it properly.

• The more javascript you have, the bigger the relative incentive to have it not re-executed upon every "page load". Any framework you include on a page has to be initialized before it can be used, and that requires parsing and executing its code... on every page it's used. SPA only needs to perform this step once (still, this is not an excuse for poor/missing dependency management).

• This also applies to CSS. When new content is added to DOM following a user interaction, there will be less re-flows and re-paints than a fresh load would incur; there is also no need for the browser to parse stylesheets again.

The real strength of a single page application is in its perceived performance. You and I both know that tapping on a link is not resolved instantaneously, but the user doesn't have to. Making the site responsive to user interactions by adding touch states and a well-timed throbber would dramatically improve the UX. Of course, you can always go the extra mile and pre-fetch certain content. Maybe it would make sense to load the next page/item/photo in the background right after the current one is ready?

Don't discard the fact that SPAs are hot and trendy, plus the motivational factor of getting to play with some fascinating frameworks. Of course, end users wouldn't care about such things, but you get to learn something new and a mature MVVM framework could take your mind off getting this damn ajax to work and let you focus on other aspects of the app.