Peculiarities between SPA and traditional web development

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.

Note

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.

Choosing a library or framework

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:

• The community behind the tool: Often, there are active communities, and it is easy to find related stuff. However, obscure frameworks/libraries tend to have a small community behind them and a reduced number of online resources.
• The frequency of updates: Outdated frameworks/libraries have a larger number of errors, and the lack of frequent updates lead to more problems than you can possibly have.
• Learning curve: The higher the learning curve for a new tool, the greater the development time of your project. In a corporate environment, this can be very costly in the delivery of your project. A low learning curve lets you become more focused on building the application without having to worry about learning and solving problems at the same time.
• Support to other libraries: This lets you remove and add things without breaking your current code. Here, you can easily replace a library or code snippet for another without affecting the application.
• Dependencies: This shows how many dependent files you need to include in your project so that everything works and how all dependencies consume resources and transfer bandwidth. Successful applications tend to grow steadily, and consequently you will need to add some more dependencies.
• Modularity: Modular applications can be easily manipulated and can be scaled progressively. Modular systems have greater flexibility and reduce development costs. A framework that enables the use of modules is strongly recommended and not limited only to SPA but for all web applications.

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:

• Libraries are snippets of codes, usually in the same file, and intended to solve a single problem. Often, they are fairly lightweight and have a very short learning curve.
• Frameworks are more robust and sometimes more heavy than simple libraries; they have a directory structure and a lot of concepts, conventions, and rules to follow. They have a long learning curve.

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:

• Bootbox (simple alert messages)
• Knockout (data binds and observables)
• jQuery (DOM manipulation and effects)
• Rivets (data binding and templates)

The following are some frameworks; they all adopt a standard MVC/MVVM, as already mentioned:

• Ember
• Angular
• Kendo UI
• Backbone
• Meteor

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.

Note

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:

• How big is your project?
• Have you previously defined a structure or pattern?
• What kind of tasks you need to solve and are they simple?
• How short are the deadlines? Will you have time to learn a very complex framework?

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.