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

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.