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 in rapid) while switching between the pages, is creating the site as a Single Page Application a good idea?

I know there are many tips you can do to increase the overall performance of a mobile website:

http://www.slideshare.net/blazeio/mobile-web-performance-optimization-tips-and-tricks

But my primary concern is that the client-side JavaScript (such as AngularJS) would actually decrease the performance, when it needs to do AJAX-requests and then show/hide/create elements dynamically, compared to creating a traditional HTTP request to get page and its contents and showing that directly.

Any resources or comments that could help me understand what architecture would be more suitable for mobile sites?

Answer 1

The accepted answer is very good and I agree with it, the latest applications I have developed were mostly made using SPA.

But I would add that SPA is not the magic solution for all applications, especially when talking about "Critical Path Rendering".

---

A brief history

To achieve a fast "time to first tweet" the processing of an entire framework such as AngularJS might be a problem.

We realized that it would be harder to achieve what the customer wanted by using Angular. So we built the application without it. The application made extensive use of AJAX requests and other practices of optimization. In the end, the time for rendering the main page decreased by almost 1 second. In two months after the deploy, the customer showed an increase of 30% in sales! Ok, it was an application with simple features and had not the whole richness that a SPA usually have.

---

Again, I'm not saying that the problem is with SPA, but I think it is not definetly the end answer for all mobile applications.

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.

Answer 3

Keep it simple -

Yes Single Page Applications are a perfect fit for mobile development. SPA Frameworks such as Durandal, Angular, Backbone, Ember, etc... need only a JavaScript engine to run effectively. They are cross-browser compatible and require nothing special to operate on each individual screen size, resolution, or device, and take advantage of mobile devices' powerful engines.

What makes them so well-suited?

With a single-page application you can put all of the hooks in place for declarative two-way data-binding with libraries such as Knockout, Handlebars or Angular that will replace all of the jQuery DOM manipulation that you would use in traditional web site. This will promote re-usable components such as Directives and Custom Binding Handlers that reduces the amount of code needed and allows for easier testing, since the bindings will be re-used through out your application.

What makes them not so good for mobile?

Single Page Applications can often start down a path of poor design that will be hard to recover from (like any other development) The difference is that it is hard to find a great path to take for creating a scalable application and often first time SPA developers make assumptions. This can alleviated by taking advantage of resources (such as paid support, StackOverflow, etc...) or by performing heavy code-review up front around the foundation of your SPA

What about performance?

Single page applications are lightning fast in most cases. The basic idea is using dependency injection and libraries like Require.js for loading AMD modules allows the developer to only require the clients to download the HTML and JavaScript files rarely when changes occur. By loading from cache you are essentially reducing your hits to the server to data calls. This follows RESTful web development techniques.

Answer 4

TL;DR: Yes, it's feasible but you need to be disciplined and the benefit is on perception of performance

I've been working on transitioning a traditional server-centric "desktop" web application to a responsive SPA over the past few months. Specifically we've chosen a MV* design supported by a mediator router an decoupled fetching with AMD. We're exploring shifting this to RVP.

I've included some of our design principles below:

• Decide early the extent to which your platform will support progressive enhancement. Less scripts that are needed the better. We rely on our build process to ensure we can support dynamically generated but statically served HTML and other content
• Build your toolchain early (minification, image crunching or spriting, etc)
• Decouple fetching from user actions as much as possible, with use of local storage and techniques like pre-fetching or predictive fetching.
• Ensure you measure what your users are doing so you can (if it makes sense), progressively fetch application logic or content
• Be really fussy on which frameworks support the rest of your architecture (rather than dictate it).
• Be really fussy on which third-party components and utilities you use. Avoid frameworks where you're not using a significant proportion of the feature set (anything you're not using is extra cost in weight, latency, on-device processing, etc)

You may find this framework comparision useful

Answer 5

The short answer is yes.

Every second counts, people start abandoning your service if it takes anything longer than a second to load. So load only what you need.

Also, google has kindly provided this fantastic set of guidelines to help you get optimized for mobile.

I've had a fair amount of success using tools like RequireJS to load on the bits I need (and organization!). This can be paired with the framework of your choice like BackboneJS, AngularJS, EmberJS ... there's plenty of great one's out there.

The most interesting framework I've seen yet is Famo.us, they claim 40-60 fps on phones, PCs, and TVs. And their demos work flawlessly on mobile.

Answer 6

SPA is good choice for mobile sites. The following template seems good performance on mobile SPA sites

Hottowel
(Overview)

With the less response time you can able to achieve great performance. I have tried the above template to create web site which supports both mobile browsers and web browsers as well.

1. Use the jquery to make the dynamic process
2. Use the ajax call to make the quick calls to data as needed
3. MV architecture will give you a clear picture to implement your concepts
4. HTML5 will be the better choice for front end
5. Use separate API to handle data process which will increase your performance

Answer 7

The turning point for this decision is the complexity of the development. Regular web-server based apps, are easier to develop because there are much more developers out there who know all the tricks how to make such application to perform at maximum effectiveness. SPAs on the other hand can achieve better performance in all areas 1) faster data transfer, 2) faster GUI(DOM) operations, 3) smarter UX, but all of those will require more experienced(expensive) developers who can make it fast and reliable. Those devs are fewer. If you plan to do everything yourself it means longer learning curve for you and a lot fo trial/error. This is mostly because SPAs are new compared to regular WWW.

To make an effective SPA you need to know the connection/socket part very well, know the bottlenecks, how protocols are chosen, what platforms (devices) support which connection protocols. Just choosing your preferred solution is not easy: Engine,IO, Socket.IO, SockJS and others.

You will need to know DOM manipulation very well in terms of dynamic performance, to wisely choose between divs/tables/canvas.

You will need to effectively use browser side abilities to store data, i.e. cookies, cache, local data storage facilities (files/db) to store data during the session and between the sessions.

JavaScript these days is very fast on iOS/Android, so the speed of language itself should be not a problem anyway. The great advantage is to use Node.js so that you can program in the same language both client and server sides. No need to sync hashThisPassword() functions across two (or more) languages.

Answer 8

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.