What we see in this new world of web applications is an analogy to what had formerly been in software development on the server side, such as Model View Controller (MVC) or Model View Presenter (MVP). We will see Model View ViewModel (MVVM) in more detail in the next chapters.

SPA has attracted a large number of developers lately, but what's so special or controversial in this development mode? What do these acronyms, MVC, MVP, and MVVM mean?

The answer to these questions is very simple; we can say this is all about JavaScript!

Wait a minute, JavaScript? You should be asking, "But what about HTML, CSS, server languages, and databases?" We'll understand it all and introduce what we call the full-stack developer using MEAN. However, we will take one step at a time.

Before we dive into the working of SPA, we need to learn about the MVC architecture.

MVC is a software architecture pattern that emerged in the 1980s, and it separates the visual representation of information from the user's interaction.

However, we are talking about the MVC pattern on the client side, for example, JavaScript running on the client side, to be more specific, the web browser. Note that the majority of SPAs transfer to a web browser all the MVC logic used on the server with languages such as Java, C#, and Ruby.

We use JavaScript to model our application according to the standards of MVC on the client side and not on the server.

Another very important aspect is to understand what represents each development model, take a look at the following:

Later in this chapter, we will see in more detail about these concepts. For now, let's take a look at the first appearance of MVVM.

In 2004, Martin Fowler published a small article about a design pattern called Presentation Model. The following is the pictorial representation of PM:

Approximately one year later, in 2005, John Gossman, a Microsoft architect for Windows Presentation Foundation (WPF) and Silverlight, revealed a new pattern on his blog, this time named as Model View ViewModel.

MVVM is very similar to Presentation Model; both patterns have an abstraction of a View (on the frontend, the view concept is what the client sees), which contains a View's state and behavior. The difference between them is that the MVVM model is more standardized and has been used in Silverlight for many years.

MVVM is based on MVC and MVP, which attempts to separate more clearly the development of User Interfaces (UIs/frontend) from that of the business logic and behavior in an application.

You might be asking, "but what does this have to do with SPA?"

Nowadays, we can clearly see this type of implementation applied to some JavaScript frameworks such as Durandal.js, Kendo UI, Ember.js, AngularJS, and Knockout.js among others. Each of these has its own way to implement it; however, they have the same concept. The following is the pictorial representation of MVP:

Almost all the frameworks that we have today follows the standard MV* pattern. Now, let's review the concepts of MVVM:

Views and ViewModels communicate using data-bindings and events. The following is the pictorial representation of how MVVM works:

For a better understanding of MVVM, let's take a look at the two-way data binding, which is the core concept and one of the most important pieces in SPA. Due to data binding, we can update the interface with the changes made in the model and vice versa.

The concept of data binding is simplified as the process that establishes a connection between the application UI and business logic. It can also mean that when data is changed, the underlying data will reflect that change.

Let's see a more practical example in analogy to a JavaScript object.

Two-way data binding refers to the ability to bind changes to an object's properties to changes in the UI and vice versa. In other words, if we have a user object with the name property, whenever we assign a new value to user.name, the UI should show the new name. In the same way, if the UI includes an input field for the user's name, entering a value should cause the name property of the user object variable to be changed accordingly:

var user = {
  name : "fernando",
  age : 25
}

Both MVP and MVVM are derivatives of MVC. The key difference between both is the dependencies each layer has on the other layers, as well as how tightly bound they are with regard to each other.

In MVC, the View sits on top of our architecture with the Controller below it. Models sit below the controller, and so our Views know about our Controllers, and Controllers know about Models. Here, our Views have direct access to Models. However, exposing the complete Model to the View might have security and performance costs, depending on the complexity of our application. MVVM attempts to avoid these issues.

In MVP, the role of the controller is replaced with a Presenter. Presenters sit at the same level as views, listening to events from both View and Model and mediating the actions between them. Unlike MVVM, there isn't a mechanism to bind Views to ViewModels, so we instead rely on each View to implement an interface and allow Presenter to interact with View.

Pretty simple, right? However, we must be very careful in choosing the best tool for our work, or we can further complicate the performance of our application. The following screenshot shows an overview of the MVC, MVVM, and MVP I/O flow:

Of course, we have more names to care about such as Router, Collections, Events, and Sync but they are part of different implementations, as discussed in the book later.

There are numerous points to consider before building a new app; to make matters worse, the expansive web development landscape can be intimidating at the outset, but don't worry, we will detail everything.