Let me now give you a brief overview of Single Page Applications.

What are Single Page Applications?

How are they different from the websites that you might have developed earlier?

For example, the website that you developed in the previous course of this specialization,

where you had multiple pages - why are Single Page Applications interesting

and what is it that you need to be aware of

when you're designing Single Page Applications?

This lecture is not intended to be an entire treatise on Single Page Applications,

but really, give you enough introduction

to get you started on thinking about Single Page Applications,

especially in the context of Angular.

Before we understand Single Page Applications, let's take a step back

and look at how traditional websites work.

In traditional websites, so far - if you visit a website,

you may be requesting for access to a particular page.

For example, you will be requesting for an index.html page

when you navigate to the website,

either by clicking on a link

or by typing the address of the website into the address bar of your browser.

So typically, the index.html page is the first one

that you fetch when you visit a website.

And when the page is downloaded from the server to your browser -

and then this will be displayed in your browser.

Now this may include not just the index.html page, but also other resources

that may be needed to be downloaded in order to construct the index.html page.

In this case, the index.html page may require additional resources,

like images or data, to be downloaded before the index page can be constructed.

But now, subsequently, if you navigate to another page in your website

- say, for example, another page like contactus.html,

this will result in your browser sending another request to the server

to fetch that second page.

So it will initiate an entire request to the server

and all the resources needed for constructing

the second page will have to be downloaded from the server.

So as you move from one page to another page,

it will involve every new page to be loaded from the server

and this would involve a round trip time to the server

to fetch all the resources required for constructing those pages.

Now imagine that your website has many pages.

Then obviously, every single piece that your web

page requires for rendering will require a full round trip time to the servers.

What you would note is - often is that many of these pages have a lot in common.

Perhaps, for example, the header

and the footer and some other piece of information are all common in all these pages.

But still, every single new page request will require you to

- to go and fetch the entire page from the server.

Now with the use of caching on the browser site, you can mitigate some of this problems

by reusing the already fetched resources from your cache; but still,

every new page that you navigate to will require an entire page

to be reloaded from the server site.

Single Page Applications approach this problem in a different way.

In a Single Page Application, typically we have developed a web application

so when the browser navigates to the website,

then this will request for the web application to be downloaded from the server site.

So this will be, for example, contained in a master page like index.html,

which will trigger an entire set of assets

that are required for rendering your web app to be downloaded to your client site.

Now how these assets are packaged depends upon how you design your web application

and also what framework you use to design your web application.

But nevertheless, you have one single large download at the start of your web application.

Subsequent changes to the client site, for example, initiated by a click on a link,

will initiate a new request to the server site; but in this case,

very often, you're only downloading some data, perhaps in the form of JSON data,

from the server site.

So in this case, each of these may require only access to the server

just to download the JSON data, for example,

which then may enable you to completely render the new view

in your Single Page Application.

So the initial page download, the initial application download, of course,

is always there, but most subsequent interactions with the server

will be simply for downloading data, typically in the form of JSON or XML,

depending on how you design your data format.

And once the data is downloaded,

those data can be then used to render the new view within your application.

So in these circumstances,

you will save a lot of round trip time to the server for downloading a lot of assets.

Of course, the initial page load requires some amount of work to be done,

but the subsequent requests may be for very small amounts of data.

And that, indeed, is the significant feature of Single Page Applications.

Now with pre-rendering of some of their views on the server site itself,

you can even mitigate some of the initial downloading time for your web application.

So even Angular, for example,

enables you to pre-render part of your first view on the server site

to enable the display of information to the client quickly,

while the rest of the web application is being downloaded by your browser.

So we can summarize that Single Page Applications

as a web application on a website that fits into a single page - again,

give or take - you - you know, don't interpret it too literally.

So you don't need to reload an entire page again.

So that is the significant feature of a Single Page Application.

Also, Single Page Applications enable you to deliver a user experience

that is more closer to work they see with desktop applications.

Once the initial web app is downloaded; thereafter,

most other interactions would seem like you are interacting with a desktop application.

So to summarize what we have just learnt, what is a Single Page Application?

A Single Page Application is a web application or a website that fits into a single page.

You don't need to reload the entire page every single time a user interacts

with the application.

The UX is more like a desktop or a native application.

Most of the resources required for your application

are downloaded at the first instance itself, with the first page load.

Thereafter, only parts of the page are redrawn,

based upon how the user interaction happens without requiring a full server round trip,

for fetching all the resources that you need.

Of course, this doesn't come without its own set of issues that need to be addressed.

So when you design Single Page Applications, one of the first things

that people often question about Single Page Applications

is that they are not optimized for search engines.

So search engine optimization is an important part that needs to be addressed.

So if you have search engines

that crawl your website to extract data and index information,

then Single Page Applications may not necessarily be cooperative in this case.

But even search engine optimization with the current data frameworks,

like Angular, have come far down the road that even with Single Page Application,

search engines can essentially index a lot of the information

that your web application serves up.

The second issue to be addressed is how much of the web construction should be offloaded

to the client site as opposed to the server site.

So the server is pretty much acting as a data source in Single Page Applications

and much of the work is offloaded to the client site.

From one perspective,

this gives you much more scalable way of delivering your web application

to your client site, because much of the rendering work is done on the client site.

Now you can optimize this to some extent to offset the initial download

of the web application from the server site

by doing part of the rendering on the server site.

As I mentioned, Angular does provide you with an opportunity

for doing that with partial server site rendering

of your initial view of your application.

The third aspect is how to maintain history so when you click on a back button

or a forward button, where would you take the user to?

Do you save enough information

that you will be able to navigate among the different views of your application and so on?

So that is one thing that you need to keep in mind.

Of course, because the Angular router leverages the html five-page history API,

so it is able to address this issue to a large extent.

The final question that we have is analytics.

How do you support analytics on your web page?

How do you collect the analytics data and so on?

And also, as I have mentioned earlier, speeding up the initial page load

is something that is of concern when you are designing your web application.

Now with Angular, as I said,

doing partial rendering on the server side will speed up the initial page load

on your client site while the rest of the web application

is being downloaded to the client site.

So you can mask a little bit of the initial download time for the web application

by doing partial rendering from the server site itself.

With these basic ideas in mind,

let's now go and explore how Angular supports Single Page Applications.

We have already incorporated the Angular router

into our Angular application in the previous exercise.

In the subsequent exercises in this lesson

and assignment, we will complete the development of the Single Page Application

that we have been working on so far in this course.

Single Page Applications

Front-End JavaScript Frameworks: Angular

Conheça os instrutores