What is a Single Page Application?

In the post- How to master Front-End Development? , I mentioned Angular is useful in building complex single-page applications. In fact, with the growing popularity of Angular, this term has become quite a buzzword (maybe the other way round).

The term Single Page Application (SPA) can be a little bit confusing in the first impression because hardly any website that we come across seems to have only a single page. In fact, a real-world complex website may have hundreds of pages.

Some of the biggest websites that we know- Facebook, YouTube, Gmail, Twitter, etc. all are SPAs. So, why are we calling such complex websites Single Page Applications? And, if they are Single Page, then what is Multi-Page?

To understand this let's first go through some ways in which a website can be built.

Static Websites

In the HTML section of How to master Front-End Development? , I illustrated the snapshot of a simple HTML page I designed long back. It was a replica of my school exam question paper.

Let's say I decide to create a website that will just contain these question papers for anyone to refer to. The most natural way would be to create a server that serves this static HTML page whenever someone visits a certain URL (maybe, www.schoolexamsarchives.com).

I know that the content of my website isn't going to change that much as it's just kind of archives. And once or twice when I need to change it I can simply edit that HTML being served and I am good to go.

Also, the website has two more sections- About and Contact Me. When a user opens one of these sections, a different HTML page is sent back from the server to be rendered in the browser.

So, that is a Static website basically with 3 HTML pages.

But what if we need to deliver some content that may change?

Dynamic Websites

Let's say I want to build a simple web application that generates invoices. People provide their names, the products purchased and their prices, etc. The server receives this information and based on a template it prepares an invoice based on the information it received and returns the invoice back to the browser.

You can think of similar use cases of a dynamic webpage on your own.

This forms a dynamic website.

Multi-Page Applications

Till now, the examples that we saw had 1 thing in common though- Each time we navigated to a different section on the website, the browser sent an HTTP request to the server. The server either returned back the static HTML pages or some HTML pages with dynamic content.

And this is how traditional websites used to work. And still, most of the websites on the Internet work like this only. These are called Multi-Page Applications (MPA) because there are several separate HTML pages which the server is sending based on the request.

But, there were few shortcomings in this approach. The major one being the User Experience (UX).

Single Page Applications

An HTTP request is a costly operation (the expense being time). In the process of sending a request, the server processing that, and then the server returning a response, we experience a delay. The delay can be more or less depending on the internet speed, load on the server, etc. Now, usually on a website every time you will be clicking some link, navigating somewhere, etc. And at every click, the process of HTTP request and response is going on which slows down things and the user has to wait till the page loads.

Out of this requirement of a better UX, the idea of Single Page Applications originated. In a SPA, the server sends a single HTML page only once. But that HTML remains attached to a lot of JavaScript code. Now, whenever we click a link or navigate to a certain URL, the Javascript running in the background changes the content of the HTML. So, there is a single page of HTML but effectively the content inside of that page is being changed.

This way, the request for a different HTML page was never sent to the server and everything happened inside the browser itself. This reduces the delay significantly and gives a feeling of almost instant loading of everything thus enhancing the User Experience.

Note:- A HTTP request may still be sent to load the data on that page but usually in those cases a JSON response is returned and the overall layout remains almost the same which saves time.

Furthermore, sometimes the difference between the look of the webpages of two different URLs on a website is very little. In a SPA, the JavaScript code just changes the part which was different (the rest of the page being exactly the same). However, in MPA even for this little change an HTTP request and response is necessary.

Probably, the simplest way to know whether a website is SPA or MPA is to watch for the Reload icon in the address bar of the browser. Let's say we open Amazon. After the homepage completely loads, try navigating around the site through different links. Notice, as you click the reload icon changes to an 'X' for a while indicating that the page is reloading. This usually means that it's a Multi-Page Application.

On the other hand, let's go to Flipkart for the same test. Does the reload icon still changes to 'X'? Notice, the URL will change while clicking different links but the reload icon does not change. So, effectively the page is never reloading. This is a SPA.

I also have one interesting observation. In your browser, open LinkedIn in one tab and Twitter in another tab. Wait for the homepage to completely load, then disconnect your internet connection. Now, click on the 'Sign In' option in the navigation bar of the LinkedIn page. Notice what happens. Now, click on the 'Log In' option on Twitter's homepage.

Noticed the difference?

Twitter successfully navigated you to the Login route but LinkedIn fails to do so. The reason is probably that in a disconnected state, the browser fails to send an HTTP request to the server. Twitter is a SPA hence, it is switching routes through JavaScript rather than getting the page from the server hence we successfully got the page rendered but LinkedIn being an MPA couldn't.

Note:- Some websites can also implement a combination of these approaches. For few pages on their site, they may render it through JavaScript, and for the other, they may get it from the server.

Finally, there is one more thing. All the above things that I talked about and the buzz around may give a feeling that SPAs are better than MPAs. But that's not necessarily the case. SPAs also have their drawbacks. The major issue being SEO.

GoogleBot traditionally used to get the links on a webpage and then crawl those links. That's how Google gains more information about the site. But now with SPAs, it's not that simple. Now, it also has to parse the JavaScript. This may affect the ranking of the website on search engines.

It's a high chance that Google will modify the algorithms of its web crawler in the future to overcome this issue. But as of now, the general suggestion that's given is- if SEO isn't that much of a problem for your site and you want a good user experience, SPAs should be the best choice for you. On the other hand, if SEO is critical to your website, it probably is better to stick to the traditional MPAs.

For more insights, you may watch this awesome video:-