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

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 2

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 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

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 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

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.