MVP is a variation on the MVC architectural pattern in which the Presenter component replaces the Controller. The Presenter also acts as the Controller in this pattern, but it takes on additional responsibility in that it serves to handle presentation logic for the View. The reasoning behind this paradigm is to enhance the testability of an application by having the View itself contain little to no presentation logic.

Another key difference between MVP and MVC is that a Presenter in MVP has a one-to-one relationship with a View, meaning there is a unique Presenter defined for every View, whereas MVC allows the Controller to have a one-to-many relationship with the View. In other words, MVC allows there to be any number of Views defined for a Controller and each View is mapped to an action of that Controller. MVP maps only one View to a Presenter. Additionally, MVP prohibits a direct relationship between the View and the Model, which is again for enhancing testability by keeping business logic out of the View:

(Diagram from Wikipedia - https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter)

MVVM is yet another variation on the MVC architectural pattern. The ViewModel in this paradigm is a representation of the Model data for the current user's session. Changes to the ViewModel are always made before any changes are made to the Model.

MVVM is like MVP in that the View has no knowledge of the Model, but in contrast, the View has a many-to-one relationship with the ViewModel. This means that multiple Views can be mapped to one ViewModel. The ViewModel component also contrasts with the Presenter in MVP in that it has no knowledge of the View. Instead, the View has a reference to the ViewModel, which allows it to be updated based on changes to the ViewModel.

The primary distinction of MVVM from the other architectural patterns in regard to SPA development, however, is the support of two-way data binding. This means that changes to the ViewModel are automatically reflected in the View, and changes to data in the View by the user are automatically updated in the ViewModel. This makes MVVM a more viable pattern for modern SPA development because the View can be updated and stays in sync with the ViewModel without the need for a new page request, which is what would be required in a traditional MVC or MVP architecture:

(Diagram from http://social.technet.microsoft.com/wiki/contents/articles/13347.mvvm-model-view-viewmodel-part-1.aspx)

Data binding will be discussed further in Chapter 6, Data Binding, and Why You Should Embrace It.

Now you should have a basic understanding of the MVC architectural pattern and the MVP and MVVM variations of it. A full understanding of these concepts is not necessary to move forward with learning JavaScript SPA development, but it is important to have some knowledge of the types of components that can comprise a multitier stack. Shown here is a diagram highlighting the key differences between the three architectural patterns discussed in this section:

(Diagram from http://geekswithblogs.net/dlussier/archive/2009/11/21/136454.aspx)