In an earlier Treehouse course, we saw how we could create a web application

using ASP.NET MVC to render HTML forms.

In this course, we'll be working with the new version of this application,

one that is built using Google's Angular framework.

The first version of the Fitness Frog web app uses ASP.NET MVC

to render a series of views or pages.

For example, when a user requests the homepage, the server retrieves

the data for the user's tracked fitness activities from the repository and

renders a view containing a list of entries.

The final rendered HTML content is returned and

displayed in the user's web browser.

Whenever a user adds, edits ,or deletes an entry,

another request is sent by the user's web browser to the server, which renders and

returns a complete webpage to be displayed in the web browser.

This process, which is repeated for each action a user takes in our web app,

is known as the HTTP Request-Response Cycle.

The new version of the Fitness Frog web app is built using the Angular framework.

The HTML, CSS, and JavaScript that makes up our web app, along with

the JavaScript for the Angular framework, is requested from the server and

loaded into the web browser as part of the user's first request.

When the user performs actions in our web app,

requests are made using Angular to an API running on the server.

Angular makes these requests in the background, so

that the initial page that was loaded stays loaded in the web browser.

When the API on the server returns a response, Angular will

update the state of the web app, including modifying the currently displayed

page in the web browser to reflect the success or failure of the user's action.

As long as the user keeps using our web app,

the initially loaded page will stay loaded in the web browser.

Because of this,

these types of web applications are known as Single Page Applications or SPAs.

Single page applications enable new ways of thinking about the design of web apps.

This is made possible by the simple idea of delivering your web app to the user's

browser as a single page, and keeping that page loaded throughout the user's session.

Let's compare the two versions of the Fitness Frog web app.

Let's start by looking at the original version of the Fitness Frog web app.

The version that uses ASP.NET MVC to server-side render each viewer page.

Our home page is the Entries list page, which shows us a list of our entries.

We can click the Add Entry button here in the upper right hand corner

to add a new entry.

All of the required fields have default values, but if we remove a value, and

click Save, we can see the client side validation keeps us from submitting

the form until we've provided all of the values.

After adding the new entry, we're redirected back to the Entries list page.

We also get a notification here at the top of the page

that tells us that the entry was successfully added.

To edit an entry, we can click the Edit button on an entry row.

And to delete an entry, we can click the Delete button.

When deleting an entry, we're taken to a page to confirm that deletion.

And now, our entry has been deleted.

Let's take a look at the SPA version of the app, the Fitness Frog client app,

to see how it compares to the server-side rendered version.

The Entries list page looks very similar, at least at first glance.

Overall, the visual design of the app is consistent with the server-side rendered

version of the app.

The Add Entry page also looks very similar.

And it has client side validations to keep us from creating an invalid entry.

Notice that notifications are implemented differently.

Toastile notifications can be used here, because the page is never unloaded.

Now, let's try editing an entry.

Instead of being sent to another page, we can edit an entry with inline editing.

This approach keeps the user in their current context.

Now, let's try deleting an entry.

And again, instead of being sent to a different page,

we can confirm the deletion right here on the Entries list page,

which keeps the user in their context.

While the SPA version of the app isn't dramatically different from

the service side rendered version, it does have some nice,

user-focused improvements like inline editing and deleting.