Why do we need a Single Page Application? [closed]

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.

Answer 1

---

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!