JavaScript Frameworks

By Matt McCabe - Web Developer.

The web has come a long way since jQuery was released in 2006 to help simplify scripting of HTML across multiple browsers. This could be anything from moving an element around the screen to toggling visible elements or creating new elements on the fly. You can achieve anything JQuery does in standard code, but JQuery makes things easier. Even if you factor in using a CDN (Content Delivery Network) to host jQuery, for the most part it's an unnecessary overhead. The new features in ECMAScript 2015/6, the first big update to JavaScript since 2009, will make it even easier to drop it and use Vanilla JS (aka JavaScript).

However, the demand for websites that provide an application-like experience has meant that frameworks are stepping in to reduce the complexity and increase standardisation, allowing you to concentrate on the business logic and specifics of your application. Avoiding spaghetti code like I mentioned in Anti-Patterns: Do’s and Don’ts is one of a developer’s big aims as this results in a buggy and hard to maintain application. Gmail, Trello, Airbnb or Basecamp are examples of what would be considered a web application; while they also have native iOS and Android apps, the experience of using their websites is almost the same.

These frameworks vary from a client-side framework like Backbone.js (used by Airbnb) or server-side framework like Ruby on Rails (used by Basecamp) to a more recent Isomorphic JavaScript application (like Meteor) that can run on both client-side and server-side. However, the architectural patterns used are commonly one of the following three:

  • Model-View-Controller (MVC)
  • Model-View-Presenter (MVP)
  • Model-View-ViewModel (MVVM)

I’ll go into MVC in a bit of detail in this post, and cover other frameworks at a later date.

Client-Server systems?

While I’ve been learning about client-server systems since high school it’s worth describing what I mean in this case.

  • Client – this is usually your browser but could also be an application on your phone or other device.
  • Server – this is where the website or application and database are housed. 

example of thin client-server systemThe example above is what would be typically referred to a thin client as the applications runs entirely on a server. These frameworks typically provide an entry point into the application via a series of requests or form inputs; for example, accessing a hyperlink like


would return the complete page for Product 1 to the browser and then suppose you wanted to edit it then you'd use


In this type of applications, the client (your browser) is doing very little and the server is doing all the work, including returning the full web page to the client. This is not a very efficient way to use a user interface and can be unresponsive. There have been improvements over the years to move some of the framework to the client. AJAX is an example of this, as it enables you to load information without reloading the whole page.

Suppose that on your product details page you want to dynamically load product reviews:


While you could go to a separate page with a list of reviews, it would be better if the reviews were just loaded into a container on the screen, without needing to reload the whole page. In ASP.NET MVC this is called a Partial View and it's usually a block of HTML rather than the HTML for a whole page. While this improves the performance, most of the application workload is still on the server.

However with JavaScript frameworks more of the presentation and business layer lives in the client, a change that has been driven by the rise of smartphones. The reason behind this is to improve performance by reducing the number of (slow) roundtrips to the server. This also helps to enable situations such as offline mode or simply allows the application to continue working when a connection to the server is poor.


Like most concepts of modern software development MVC originated in the 1970s. But it didn’t become a popular pattern until it was described in details in a book I’ve mentioned previously, the Gang of Four book. If you want to read more about the history of MVC, then Martin Fowler has done a great job.

The diagram below shows how the Model, View and Controller interact with each other.

Diagram by RegisFrey (Own work) [Public domain], via Wikimedia Commons

Let’s take an example of searching for a list of products I’m interested in:

  1. The client tells the Controller to “Get list of Ultra-wide Monitors” by typing this into the search box and pressing the search button;
  2. The Controller updates the Model to get the list from the Database;
  3. The Model gets the list from the Database; typically this will mean interacting with the Data Access Layer or using a Service to return this data into the Model
    - The Model may reformat or prepare the data so it’s ready for the view
  4. The Model updates the View with the list of Ultra-wide Monitors
  5. The View displays the list in a useful format such as showing which have been discounted, what ports the monitor has or if it’s even in stock.

ultra wide screen - photo by Vernon Chan on Flickr


The model represents and manages the data for an application. In a typical application the data will be stored in a database but it’s possible it could be using localStorage (for storing data locally in your browser) until the data is synchronised with a database.

At its simplest a model is a group of attributes; for a monitor this could be:

  • Screen Size;
  • Resolution;
  • Colour;
  • Weight;
  • Etc.

Or it could be metadata (data about the data) like:

  • Measure (Kg, Stone, etc.);
  • The data type, from example numeric or alphanumeric.

Although not always true, the model could also include validation logic, for example if the post code field is in a valid format.


In the context of a web page a view could be the whole or part of a page, for example a particular DOM Object which contains a list of products. Views are generally called ‘dumb’ as they don’t contain any logic; their main purpose is to render what the controller gives it and also to trigger calls to the controller.

Calls to the controller could be as simple as requesting an updated view or you could be editing some data and posting it to the controller to be validated and saved.


Templates are an important part of views as they can have a big impact on performance. Although Handlebar.js and Mustache are fairly established templating engines, the big frameworks tend to have their own. React, Facebook’s user interface library is little bit different in that they’ve created their own file format (JSX) to include all the HTML for a view within the JavaScript.

These are all client-side (JavaScript) templates but Razor which is used by Microsoft’s ASP.NET MVC, is one used on the server-side.

The basic idea of all these templating engines is the same: to combine a model’s attributes using placeholders and some logic to create the view that’s displayed to the user.


In MVC the controller is the glue that holds everything together: without it the Model and View wouldn’t know what to do with themselves. The controller has 2 main responsibilities:

  • Receiving requests from the View;
  • Updating the model.

Using the MVC pattern you'll end up with controllers that group certain functions. A few examples might be ProductController or maybe an OrderController. This type of framework is easier to extend, maintain and test applications.

Using MVC on the web typically means developing or using a framework that implements the MVC pattern. As you'd expect there are quite a lot of those; TodoMVC does a great job of showing off the main ones by showing the same Todo application implemented in the various frameworks.


Although not technically part of MVC, you should consider routing a supporting feature as it makes it much easier to test and to understand.

You’ve probably seen it before when you looked at the address bar in your browser and I’ve mentioned it in this article; when the page address looks like this:


then it’s likely using routing to go to the Search action of the Product Controller and passing in the search term ‘UltraWideMonitor’.

Fat Model, Skinny Controller

As shocking as that might sound taken out of context of course, we’re talking about the Model and Controller in MVC. What this means is you put all of your business logic into the Model so it’s easier to understand and troubleshoot, however that doesn’t mean you make your model so big that the opposite is true.

Data binding

Another area that has crept into MVC is data binding, which is more common in JavaScript frameworks like Angular or the new kid on the block, Aurelia. Data binding is a technology that enables your view to update your model; typically this will be done ‘live’ so if I were to change my name in an input box it would be reflected elsewhere on the page, maybe even while I’m typing it.

Because there isn’t really a ‘classic’ Controller in this situation you wouldn’t usually see it as MVC, however the data-binding engine (part of the framework) does the job of the Controller. Either way it’s a big part of modern JavaScript frameworks and it certainly plays a big part in providing a slick user experience.

Why MVC?

I haven’t really talked about ‘Separation of Concerns’ specifically but avoiding spaghetti code is a big part of MVC. While you can achieve this through good coding practices, MVC is a good way of enforcing this. It also has the following advantages over using no framework:

  • Maintenance;
  • Testability;
  • Reduce duplication;
  • Improves team working due to the separation.

MVC isn’t the only pattern for designing web applications but it has become one of the dominant ones. Stay tuned for Part 2 of this blog, where I’ll discuss MVP, MVVM, MVC and more.


You might also like...