The reason AngularJS will success: Part 2

As promised, this is the second round of this series :). I will discuss today, the four George’s tests listed bellow:

  • Load elements onto a page
  • User clicks on stuff
  • Use AJAX calls to…
  • Manipulate DOM elements

I will discuss his examples one by one following the order in his post:

Ajax calls

The author include the below 2 examples:


  url: '/ajax.php',
  dataType: 'JSON',
  success: function (data) {
  fail: function (data) {
    alert("AJAX failed!");


$scope.myData = {};
$scope.myData.doClick = function (item, event) {
  var responsePromise = $http.get("/ajax.php");
  responsePromise.success(function(data, status, headers, config) {
    $scope.myData.fromServer = data.title;
  responsePromise.error(function(data, status, headers, config) {
    alert("AJAX failed!");

The author consider that jQuery have less code. But, he didn’t mention that the Angular code do more than a simple ajax call. In fact, it has this features:

  • Ajax call
  • Click event trigger
  • Two-way data binding
  • Looser-coupling with the DOM, because we don’t manipulate the DOM directly

Try to implement all this features with jQuery and you will see how AngularJS care for your time and the quality of your code. Furthermore, $http service supports JSONP and managing HTTP headers explicitly and in a fashion way.

DOM Manipulation

For this section, the author used the below example:

var myApp = angular.module('myApp', []);

myApp.directive('myWidget', function() {
  var linkFn;
  linkFn = function(scope, element, attrs) {
    var animateDown, animateRight, pageOne, pageTwo;
    pageOne = angular.element(element.children()[0]);
    pageTwo = angular.element(element.children()[1]);

    animateDown = function() {
        top: '+=50'

    animateRight = function() {
        left: '+=50'

    $(pageOne).on('click', animateDown);
    $(pageTwo).on('click', animateRight);
  return {
    restrict: 'E',
    link: linkFn

Firstable, I should notice here that he does not attack this part properly, because Angular directives are a sophisticated solution in which the purpose is extending the HTML by designing reusable component. Personally, I would appreciate that he starts by introducing Angular templating and built-in directives such as ngClick, ngHide, etc.

Secondly, the author hated the fact that we use jQuery in the above example . It’s clear now that he didn’t make any effort to understand why MVC frameworks, like AngularJS, have seen the light: Angular developers don’t want to replace jQuery but they want to provide a set of utilities to facilitate the creation of maintainable front-end applications. Indeed, they use jQuery or jqLite to manipulate the DOM.

jqLite is a tiny, API-compatible subset of jQuery that allows Angular to manipulate the DOM in a cross-browser compatible way. jqLite implements only the most commonly needed functionality with the goal of having a very small footprint.


This is the most interesting section, in which we can see the quality of applications that the author write. I don’t want to discuss this because maybe he have some reasons that I can’t imagine. But personally, I do anything to avoid write such a code. Yet, We can use this use case to highlight the power of AngularJS.

The author should separate the logic from the view. So, the back-end should send real data:

  products: [
    productA : {
      productId: 345,
      name: "product A",
      price: 120;
      imageURL: "/public/uploads/products/productA.png",
      description: "this is the description of product A",
      colors: ['red', 'blue'],
      sizes: [34, 36, 40]

We will define a Product service to wrap product list endpoint. For this use case, Angular provide an ngRessource module that make it easy to consume REST APIs.

var productServices = angular.module('productServices', ['ngResource']);

productServices.factory('Product', ['$resource',
    return $resource('products/:productId.json', {}, {
      query: {method:'GET', params:{productId:'products'}, isArray:true}

The controller should look like this:

myApp.controller('ProductList', ['$scope', 'Product', function($scope, Product) {
  $scope.products = Product.query();

and at the view level, we will have something like that:

  <li ng-repeat="p in products">
    <img src="{{ p.imageURL }}"/>
    <span>{{ }}</span>
    <b>Price: </b>{{ p.price }}
    <p>{{ p.description }}</p>

As you can see, the Angular solution is easier to understand, more elegant, more structured and less code (10/48 lines only !).

Finally, I notice that if you don’t want to send the whole data for any reason, you should send a patch for the modified data. Then you merge it with the existing one at the client level (on your Angular $service). Here comes the magic of AngularJS which supports two-way data binding.


The reason AngularJS will success: Part 1

Recently, I read ‘s post “the reason AngularJS will fail“, that reduce AngularJS’s value. In my opinion, he compared it with jQuery which are incomparable. Also, the result of the comparison is false.

Let’s discuss the idea of comparison: jQuery is a cross-browser JavaScript library designed mainly to simplify document traversal and manipulation. However, AngularJS is a client-side framework (a framework is a collection of software libraries providing reasonable default interface, and generally driven by patterns). In other words, the main differences are:

  • Libraries are generally more expressing
  • Libraries allow us to learn the API as needed
  • Framework requires holistic understanding
  • Framework bring structure to large amount of code

As you see comparing jQuery to AngularJS is like comparing a text editor to an IDE, this does not means that the text editor is not more useful, but simply because the IDE has a big scope of features than the text editor. Eventually, you can extends the text editor with new features such as auto-complete, syntax highlighting, etc and you will have an IDE.

Is AngularJS difficult ?

According to the author, Angular will fails because it’s difficult. First of all, I agree with him that AngularJS is more difficult than jQuery, and that’s intuitive because frameworks are always more difficult than libraries, but this difficulty bring us more modularity, maintainability and testability, and make both development and developer’s life more easy. However, I don’t agree with him that Angular is difficult. It’s clear that it’s not intuitive but it doesn’t mean that it’s difficult, you can learn AngularJS fundamentals in 60 minutes (see this video), yes absolutely in just 60 minutes.

In the other hands, frameworks doesn’t fail because they are difficult, but they fail if their difficulties are not worth the results they produce. A chain saw is more difficult than a saw: you must be sure that it’s fuelled up and oiled. But is it useful? If you don’t want to burden your head with application architecture and best practice, just use jQuery and manipulate the DOM by your hand and you will discover as soon as your application grow that your code sucks and you not find any solution than rebuild it from scratch using any JavaScript framework.

Is AngularJS sucks ?

Another point discussed in the first author’s part, is that « doing a google search on “jQuery sucks” vs “AngularJS sucks” shows that there are more results for the latter ». Wow !! this is very convincing. Let’s try to compare each one features in an objective way:

jQuery VS AngularJS
jQuery VS AngularJS

I notice, that we can extend jQuery’s features using 3-rd party libraries and jQuery plugins.

Finally, I want to reminder you that jQuery is a wonderful library, but it can not replace any JavaScript framework. So, when you’re in a situation that jQuery is all you need then you SHOULD USE IT.

I’m gonna discuss the rest of his post in my next posts.