Server-side web applications have been around for quite some time now. However, the Web is evolving at such a fast pace that we are driving applications from the client-side rather than the server-side. Gone are those days when the server dictates to the client about what activities to perform and what user interface to display.

With the extensive growth of asynchronous and highly interactive web pages, the user experience can be made better with client-side driven applications than server-side driven applications. As you already know, libraries such as jQuery and Zepto help us in achieving this quite easily.

Let's take a typical use case where a user enters data in a textbox and clicks on a Submit button. This data is then posted to the server via AJAX, and the response is rendered in the UI without any page refresh.

If we had to replicate this using jQuery (with a pseudo syntax), it would look something like this:

// Assuming that jQuery is loaded and we have a textbox, a button and a container to display the results

var textBox = $('#textbox');
var subBtn = $('#submitBtn');

subBtn.on('click', function(e) {
  e.preventDefault();
  var value = textbox.val().trim();
  if (!value) {
    alert('Please enter a value');
   return;
  }

  // Make an AJAX call to get the data
  var html2Render = '';

  $.post('/getResults', {
      query: value
    })
    .done(function(data) {
      // process the results 
      var results = data.results;
      for (var i = 0; i < results.length; i++) {
        // Get each result and build a markup
        var res = results[i];
        html2Render += ' < div class = "result" > ';
        html2Render += ' < h2 > ' + res.heading + ' < /h2>';
        html2Render += ' < span > ' + res.summary + ' < /span>';
        html2Render += ' < a href = "' + res.link + '" > ' + res.linkText + ' < /a>';
        html2Render += ' < /div>'
      }
      // Append the results HTML to the results container
      $('#resultsContainer').html(html2Render);
    });

});

When you click on the button, the textbox value is posted to the server. Then, an HTML markup is generated with results (JSON object) from the server and injected into the results container.

But, how maintainable is the preceding code?

How can you test individual pieces? For example, we want to test whether the validations work fine or whether the response is coming correctly.

Let's assume that we want to make modifications (such as adding a favicon of the resultant web page next to each search result as an inline icon) to the results template that we are building on the fly. How easy would it be to introduce this change in the preceding code?

This is a concern with separations. These separations are between validations, making AJAX requests and building markups. The concern is that they are tightly coupled with each other, and if one breaks, all would break and none of the preceding code can be reused.

If we were to separate the preceding code into various components, we would end up with a Model View Controller (MVC) architecture. In a typical MVC architecture, a model is an entity where you save the data, and a controller is where you massage the data before you display it on a view.

Unlike the server-side MVC, the client-side MVC has an extra component named the router. A router is typically a URL of the web page that dictates which model/view/controller should be loaded.

This is the basic idea behind AngularJS, and how it achieves separation of concerns and at the same time provides a single-page application architecture.

Referring to the preceding example, the server interaction layer (AJAX) would be separated from the main code and will interact with a controller on an on-demand basis.

Knowing this, we will now take a quick look at few key AngularJS components.