Let's now review some important points of employing the MVC/ MVVM pattern, to build web applications, instead of traditional web applications.
One of the important points is that the MVC pattern can be applied on the server side or client side. For example, we can use the MVC pattern that runs on the server using some JavaScript library as Express and build a SPA only on the server (in this case, Node.js). This is because MVC is a software architecture pattern and can be applied on both sides, frontend with MVC frontend frameworks and on server-side frameworks such as Ruby on Rails and .NET.
On SPA, everything happens on just one page; as mentioned before, there's no refresh on page request, such as in multipage applications where we have page reload on each request. All the necessary content is injected into the page through the use of Ajax and HTML templates to render the content.
We consider this the main difference between SPA and applications with multiple pages, where for each new page that is requested, we have a new request.
There are many other differences to consider, but the best tool is the one that makes you more productive. Then, the choice should be based on the project's scope, budget, and technical knowledge of the development team.
JavaScript MVVM or MV* facilitates easier parallel development of a UI and the building blocks that power it. You can have a frontend developer working on the UI, HTML templates, and data-bindings and another developer working on the server-side logic of the same page.
On multipage applications, we have HTML code generated on the server, and this makes the job of styling and customization of the user interface more difficult. Generally, we cannot have simultaneous work on the same screen.
Also, on multipage applications, the template used is the server-side template, so the web page is parsed and sent to the browser. However, in the case of SPA, the HTML code is generated on the fly according to the view, using some templates such as Handlebars and Underscores.
Frameworks generally have a greater number of methods and functions than just a small library, and furthermore its work might become more complex as the application grows.
We need to look at other important points as well:
Choosing a framework is the first and the most important choice you will make in the planning stage of the application. For sure, you'll want to choose the best framework or at least the most popular.
But how to choose? Every day we have new options emerging from simple libraries, and we also have small plugins to complex frameworks to choose from; so, how to decide?
Here, we make a simple list to ease your decision; you must keep in mind the following concepts about frameworks and libraries before you start:
We can cite the following alternatives as libraries, where each of them propose to solve a specific problem or set of problems without the need for you to follow very rigid patterns of organizing code:
The following are some frameworks; they all adopt a standard MVC/MVVM, as already mentioned:
Also, we need to mention some variations such as Durandal.js (Mixin jQuery, Knockout, Require.js), and Thorax.js (Mixin Backbone, Handlebars), which are widely used on the frontend, and others such as Express, Jade, and Handlebars (hbs) are used on the backend of the Node.js server.
Handlebars is an incredible tool to build JavaScript templates on both the server and frontend; it is very lightweight and flexible and can be found at http://handlebarsjs.com/.
From the previous list, we can say that Kendo UI has all the peculiarities of MVVM frameworks with plus points such as UI components, data-bindings, and charts. Angular.js has the power to create your own directives and the most popularity with a huge community behind it.
So, what's best for your project? We need to answer some very important questions when choosing the right tool:
These are the questions you should answer first. After this, when you're choosing, take into account how many applications are already in production that use your choice.
Trello, Foursquare, Code School, DocumentCloud, and Groupon are good examples of using some of the mentioned frameworks in real applications.
We believe that all tools have good and bad sides, the pros and cons, but we also believe that the best tool is one which best solves our problem. Thus, be careful when choosing the tool and analyze the mentioned facts well; some of them can make you save your time and money.
A very practical example is the need for nested views in templates; a precipitous choice cannot pay attention to this detail, and you will certainly have a lot of work if the chosen tool is not present in a similar default solution for nested views.
Now, for instance, you know how to use a particular library and try to integrate it with another and discover that there is no compatibility between them. In such cases, you will need more time to try to resolve this impediment.
18.119.235.79