In this post, we are going to cover the main benefits of adopting an SPA Architecture while building our Angular Applications, and answer some very common questions regarding SPAs in general.

This post is part of the ongoing Angular for Beginners series, here is the complete series:

Why the SPA Architecture?

Let’s start with the first question: Why Single Page Applications (SPAs)? This type of applications have been around for years, but they have not yet become widespread in the public Internet.

And why is that?

There is both a good reason for that and an even better reason on why that could change in the near future.

SPAs did get adopted a lot over the last few years for building the private dashboard part of SaaS (Software as a Service) platforms or Internet services in general, as well as for building enterprise data-driven and form-intensive applications.

But does Angular then enforce building our applications as a SPAs?

The answer is no, it does not, but that is an interesting possibility that it brings, given the many benefits of building an application that way. Which brings us to a key question:

Why Would You Want to Build an Application as a SPA?

This is something that is often taken for granted. Everybody is building applications this way, but what is the big advantage of that? There have to be at least a couple of killer features, right?

Let’s start with a feature that does not get mentioned very often: Production Deployment.

Understanding the advantages of SPA use in production will actually also answer the key question:

What is a Single Page Application?

Sometimes names in Software Development are not well chosen, and that can lead to a lot of confusion. That is certainly not the case with the term SPA: a single page application literally has only one page !! 😊

If you want to see a Single Page Application in action, I invite you to head over to the AngularUniv https://angular-university.io and start clicking on the home page on the list of latest courses, and on the top menu.

If you start navigating around, you will see that the page does not fully reload – only new data gets sent over the wire as the user navigates through the application – that is an example of a single page application.

Let me give you an explanation for what is the advantage of building an application like that and how does that even work.

Using the Chrome Dev Tools, let’s inspect the index.html of the AngularUniv website that gets downloaded on the home page (or any other page, if you navigate and hit refresh).

The page that gets downloaded is the very first request that you will see in the Chrome Network tab panel – that is the literally the Single Page of our Application.

Let’s notice one thing – this page is almost empty! Except for the tag, there is not much going on here.

Note: on the actual website the page downloaded also has HTML that was pre-rendered on the server using Angular Universal

Notice the names of the CSS and Javascript bundles: All the CSS and even all the Javascript of the application (which includes Angular) is not even coming from the same server as the index.html – this is coming from a completely different static server:

In this case, the two bundles are actually coming from an Amazon S3 bucket!

Also, notice that the name of the bundles is versioned: it contains the timestamp at which the deployment build was executed that deployed this particular version of the application.

The Production Deployment Advantages of Single Page Applications

The scenario we have seen above is actually a pretty cool advantage of single page applications:

Single Page Applications are super easy to deploy in Production, and even to version over time!

A single page application is super-simple to deploy if compared to more traditional server-side rendered applications: it's really just one index.html file, with a CSS bundle and a Javascript bundle.

These 3 static files can be uploaded to any static content server like Apache, Nginx, Amazon S3 or Firebase Hosting.

Of course the application will need to make calls to the backend to get its data, but that is a separate server that can be built if needed with a completely different technology: like Node, Java or PHP.

Actually, if we would build our REST API or another type of backend in Node, we could even build it in Typescript as well, and so be able to use the same language on both the server and the client, and even share some code between them.

Single Page Application Versioning in Production

Another advantage of deploying our frontend as a single page application is a versioning and rollback. All we have to do is to version our build output (that produces the CSS and JS bundles highlighted in yellow above).

We can configure the server that is serving our SPA with a parameter that specifies which version of the frontend application to build: it's as simple as that!

This type of deployment scales very well: static content servers like Nginx can scale for a very large number of users.

Of course, this type of deployment and versioning is only valid for the frontend part of our application, this does not apply to the backend server. But still, it's an important advantage to have.

But is production deployment the only advantage of single page applications? Certainly not, here is another important advantage:

Single Page Applications And User Experience

If you have ever used a web application that is constantly reloading everything from the server on almost every user interaction, you will know that that type of application gives a poor user experience due to:

the constant full page reloads

also due to the network back and forth trips to the server to fetch all that HTML.

In a single page application, we have solved this problem, by using a fundamentally different architectural approach:

On a SPA, after the initial page load, no more HTML gets sent over the network. Instead, only data gets requested from the server (or sent to the server).

So while a SPA is running, only data gets sent over the wire, which takes a lot less time and bandwidth than constantly sending HTML. Let’s have a look at the type of payload that goes over the wire typically in a SPA.

For example, in the AngularUniv SPA, if you click on a course, no HTML will be sent over the wire. Instead, we get an Ajax request that receives a JSON payload with all the course data:

As we can see, the HTML version of a course would be much larger in size when compared to a plain JSON object due to all the opening and closing tags, but also there is a lot of duplicate HTML if we constantly loading similar pages over and over.

For example, things like the headers and the footers of a page are constantly being sent to the browser but they have not really changed.

So with this, we have here a second big advantage of a single page application: a much-improved user experience due to less full page reloads and a better overall performance because less bandwidth is needed.

So Why Don’t We Use SPAs Everywhere Then?

If SPAs have so many advantages, why haven’t they been adopted on a larger scale on the public internet? There is a good reason for that.

Until relatively recently, search engines like Google had a hard time indexing correctly a single page application. But what about today?

In the past, there were some recommendations to use a special Ajax Crawling Scheme that has been meanwhile deprecated. So is Google now able to fully render Ajax?

In an official announcement, we have the information that Google search is now generally able to crawl Ajax, but there are some reports that it's yet not completely able to do so.

And the recommendation is to use Progressive enhancement instead. So what does that mean, at this stage is it possible to use SPAs in the public internet or not yet?

Search Engine Friendly SPAs?

It's possible to have the performance and user experience of a SPA together with good SEO properties: the use of the Angular Universal pre-rendering engine allows us to:

pre-render an application on the backend

ship the HTML to the browser together with Angular

and have Angular bootstrap on the client side and take over the page a SPA

Will SPAs Become More Frequent In the Future?

Imagine an SEO friendly version of Amazon that would not refresh itself at each page reload and with a much-improved performance and user experience: that would have likely a huge positive impact on the time customers spend on the site!

So the technical benefits of SEO-friendly SPAs are significant and even more so on mobile, and we would expect that these type of SEO friendly SPA applications would become more frequent in the future also on the public internet.

But this leaves the last question of this section still unanswered. You must be thinking at this stage after reading the last few sections:

If only minimal HTML is loaded from the server at startup time, then how does the page keep changing over time?

Which leads us to the last question of this section, and maybe the most important:

How Do Single Page Application Even Work?

Indeed, how can they work because we only loaded very little HTML from the server? Once the application is started, only data goes over the wire. So how does the new HTML come from?

Because there has got to be new HTML being generated somewhere, as it's the only way that the browser will change what it's displaying, right?

The answer is simple, and it has to do with the way that single page applications actually work when compared to traditional server-based applications.

On a traditional application (which includes the vast majority of today’s public Internet), the data to HTML transformation (or rendering) is being done on the server side.

On the other hand, Single page applications do it in a much different way:

In a SPA after application startup, the data to HTML transformation process has been moved from the server to the client – SPAs have the equivalent of a template engine running in your browser!

And so with this information in hand, let’s wrap up this section by summarizing the key points about single page applications.

Section Summary – Advantages of SPAs and the Key Concept About How They Work

Building our application as a SPA will give us a significant number of benefits:

We will be able to bring a much-improved experience to the user

The application will feel faster because less bandwidth is being used, and no full page refreshes are occurring as the user navigates through the application

The application will be much easier to deploy in production, at least certainly the client part: all we need is a static server to serve a minimum of 3 files: our single page index.html, a CSS bundle, and a Javascript bundle.

We can also split the bundles into multiple parts if needed using code splitting.

The frontend part of the application is very simple to version in production, allowing for simplified deployment and rollbacks to previous version of the frontend if needed

And this just one possible deployment scenario of SPAs in production.

Other Production Scenarios

Other scenarios include pre-rendering large parts of the application and upload everything to a static hosting server, in-memory caching on the server of only certain pages, do versioning using DNS, etc.

Its today simpler than ever to make SEO-friendly SPAs, so they will likely have increased adoption in the future, in scenarios where SPAs have not been frequently used.

The Way SPAs Work

The way that single page applications bring these benefits is linked to the way that they work internally:

After the startup, only data gets sent over the wire as a JSON payload or some other format. But no HTML or CSS gets sent anymore over the wire after the application is running.

The key point to understand how single page applications work is the following:

instead of converting data to HTML on the server and then send it over the wire, in a SPA we have now moved that conversion process from the server to the client.

The conversion happens last second on the client side, which allow us to give a much improved user experience to the user.

I hope that this convinces you of the advantages of SPAs. If not please let me know and why that is not the case so I can better develop some of the points.

Also, at this stage I want to show you some code straight away. Let’s build a small Hello World SPA in Angular, and take it from there. We are going to see how the concepts that we have introduced map to the small application that we are about to build.

I hope that this post helped to understand the key benefits of SPAs, and that you enjoyed it!

This post is part of the ongoing Angular for Beginners series, here is the complete series: