Why do we need a Single Page Application?

Question

The Single Page Application (SPA) has come to us. A lot of new things come with it as well, like Routing, Page life cycle at client side, MVC pattern, MVVM pattern, MV* pattern,... and some of Javascript patterns also come to us like AMD pattern, Singleton, Facade,..

A lot of SPA frameworks and libraries also were developed. We can find out some of its on the internet. They are AngularJs, Reactjs, BackboneJs, DurandalJs,.. and a lot of third party components to make the Javascript coding more easy like RequireJs, Amplifyjs, BreezeJs...

But I just think why do we need the SPA? Because it's seen to be introducing some of new complex things in developing the web application. Inspite of the SPA, we can use the traditional web application, each request each loading page. I just see a benefit like we can be easy to run it on the mobile and adapt with a new web application development trend. Could somebody explain more clearly about that?

One more thing, if we use a lot of third party components to composition just one SPA. So does it make a consistency for this web application? I think it should make a complex for maintain a huge components inside our web application. How do you think about that?

All suggestions are welcome.

Solution

---

I believe that this is the direction most websites should be moving in considering the number of devices that users utilize today, and the abilities and limitations of each.

---

IMPORTANT:

Before reading the rest of this, please understand that this concept is built on the foundation of basic principles of designing for the web. In order to design a single page application for all devices and situations, it cannot be run exclusively as a single page application. You must build a foundation that will work on the most basic of browsers with highly limited features and enhancing the user's experience according to their device's capabilities.

This may cause more work for you, but you will be capable of satisfying a larger and more diverse audience, which is much more impressive than throwing together a web app built only for modern desktop or phone browsers specifically.

---

---

Decrease load time and/or weight

Single page applications are more capable of decreasing load time of pages and the amount of data transfer from server to client.

Some of the most heavily impacting features of this method include :

• storing any global functionality once it is loaded the first time,
• allowing easier data transfer between pages and a more complex user interface
• removing the cost of loading a whole page after a postback when you only need specific components

Increased chance of over complicating

This design method may allow for laziness in the developer and more interference from an end user. As a developer, be sure that your UI does it's job (get, display and submit to server) and that the server does it's job (provide, validate and submit to database). Most end users won't attempt to break your system using the information in a javascript file, but including information about your data structure is asking for trouble in my opinion.

Start with a strong architecture!

As with any webpage, the processing of data can be moved directly into service handlers instead of pages which could result in an architecture utilizing the following layers:

• Database (Data Storage)
• BL (Data Handling and Transport)
• User Interface (Data Display and User Interaction)

Services over page handling

In my opinion using services is pretty much a requirement for organized and modulated code in a website. The standard get and post methods used in backwards compatible website can also use these services to hit services representing business objects instead of pages. This allows your code to be more generalized across modules concerning the same objects.

The update to a single page application then becomes simplistic in that you can initialize any UI to pick up the get or post methods and perform them using AJAX methods instead of causing a postback for events, thus a single page instance.

A side effect of using these services to handle UI events is that you eliminate the need for event handling in a code behind file except for life cycle events. The life cycle events are useful for handling and modifying relevant data to display based on the situation as well as modifying the returned html to lighten the load on the user's device.

Deferred Loading!

Any complex website will come with complex modules and plenty of unique components.

A benefit you gain from using a single page application is that you have the option to deffer the load time to an ajax process and do so whenever you like for any part of your application (i.e. first attempt to use a module, dead time after initial page load, etc), making the initial load faster and the processing time more controlled.

My list of best practices

As for best practices.. there are quite a few optimizations that could and should be made to a design intending to use this method, such as :

• storing information as it comes, obliterating when no longer relevant
• loading in script, html and js files through ajax only when needed
• using data loaded on one page in another if it can be instead of reloading for each new "page"
• minimalist data structure for the UI since it is a means for displaying and not for processing.
• don't obsess with validation on the UI because your services should already be built to validate any information submitted to it

These optimizations are helpful with load time, data handling and object associations. Obviously this is not a complete list, but it is a great head start to building you single page application.

Finally, I would suggest researching concepts for designing for one web to help build a solid foundation. After that, the rest is relatively simple enhancements. (TIP: One of those enhancements is to catch all actions resulting in a postback and use the information to build a asynchronous call instead).

There is all sorts of information on this, and all sorts of libraries to use, but I would suggest using your own code as much as possible for the basic functionality and to get into the library code that solves your issues and do some research instead of trying to implement a complex system with generic library code. Using their code as an example may lead to a smaller overhead and stronger code for your specific situation.

Good Luck!

Comments

[Ben McCormick]

Could you consider narrowing down your question? You asked several questions here, most of which are quite subjective. Your question is likely to get closed as a result. If you have a specific question that can be answered objectively, please edit down this question to express it.

[user1212212]

"White-screen, scroll-to-top, wait on a mobile radio for 5 seconds" is a failed experience. You lose mindshare, sales, and waste the time of those you're trying to impress. Sites are complex nowadays and re-interpreting css, fonts, etc is unnecessary with a SPA. Owning retry logic is also nice.

[Alex]

A lot of SPA frameworks... I would say it's major one - AngularJs, and all the others which combined take less market share than single AngularJs. If you want to learn SPA especially with AngularJS, check out this tutorial.

[Toskan]

Loadtime: heard of 5G and 4G? Wasting weeks on optimizing load time a tiny bit might likely not pay off at all. Heard of http 2? generic service: this should always be like that. The only difference is that SPA sends back and forth json. But in the end you have to use a js framework to render your page. That much to it being generic. BUT: the page rendering which comes at a cost, is done by the client. Less computing cost on the server. Heavy weight applications with HUGE traffic are cheaper like this. That's for sure.

[Brett Weber]

I agree with these statements. If you have any comments that would improve this answer beyond what I have displayed given my experiences, I would appreciate an edit greatly. Personally, I do not know enough about 4G or 5G to add to this much further nor do I have enough experience in optimizations to add to that effect.

[gm2008]

@Toskan: It is not that absolute. CPU's speed, computer RAM and network speed have been increasing fast. Maybe doubled every few years, but the load of computing humans impose on computers are increasing at a synchronized pace as well. When talking about the concurrent hardware available, single page apps still make a difference and offer better user experience. On the whole, within MVC architecture, more of the tasks are shifting to the client end, when the browsers are becoming more mature and client end machines are faster.

[Toskan]

@gm2008 please cite a reference stating that one page apps offer better user experience. Imho the user will not even realize the difference. ux.stackexchange.com/questions/61013/…

[Toskan]

probably a good example is gmail. You start writing an email, e.g. you click compose then you start writing. Enter text in the textbody. Now click on sent emails or a similar link. While the page is loading, click back into the text body inside the text. You will realize that the loading only happens in the inbox, but does not affect the compose email section. This kind of behavior is probably where SPA can score.

[thangchung]

@Toskan Thanks for your explanation. It is really good to know about this

[User101]

As a developer now asking 2 years after this answer was accepted, are Single Page Apps still getting the same hype as before? Now we've seen the silver bullet and tried it in anger, have people found issues with SPA's e.g brittleness etc? How successful have SPA's become on the mainstream web (apart from the obvious google examples).

[mico]

I think that the main point is that in a SPA it is obvious where context is and where client side app data lies. In a MPA, I think that scripts would be loaded and discarded many times, reducing the benefits of just in time compilation and losing the controller state, which should go back and forth between page and local storage.

[Brett Weber]

I love how this answer has lasted this long and still gets attention regularly. I would like to see some edits on the question to build and refine on an outline of the methods involved in establishing a single page application. Some day it will come. ^.^

[Manachi]

I've worked on extremely large applications, both SPA and traditional for over 17 years. To be honest I feel that SPA is overrated and overcomplicated in many ways, and I miss the simplicity + benefits of traditional applications. I wouldn't be surprised if SPA dies over time.