26. November 2015

AngularJS, BackboneJS, similarities and differences.

When learning a new framework or library, its very difficult to look at the same problem from a different perspective. But when you hear a lot like ‘ohh, that library is similar to this’, then the tendency comes to compare it. And when you see similar terminology in both the frameworks, then you are absolutely sure that both are doing the same thing in the same way. I think, thats the main problem here with learning the frameworks like AngularJS and BackboneJS. Both of these have their own share of how to and where to, overall they seem completely different, even though the terminolgies seem completely same.

One such thing is Module. Both these frameworks define Module and use it. Both of them tell to use Module to separate concerns. But then both of them seem completely different while implementing the Module. Umm, Why?!

The difference is in the Module definition of both the frameworks. And that pushes back someone very new to the frameworks, thinking something wrong either in the frameworks or in the understanding of them. While the truth is something simpler than that.

AngularJS uses CommonJS module declaration.
BackboneJS uses AMD module declaration.

Once you know this difference, things get a lot easier to understand and will take lesser time than before to get upto speed in either of these. Have a look at the Module Definition documentation, it explains the difference of the module definitions. The bottom line is Javascript eco-system gives us two different kind of Module systems. Frameworks use one over the other depending upon their opinion. For example NodeJS uses CommonJS approach, while DOJO toolkit uses AMD way.

Now lets understand why this difference matters us as a developer. In CommonJS style declaration, each file is supposed to be a module which is same as AMD way too. The CommonJS module can expose as many Objects as one wants, to the application level. So that once one CommonJS module is included, the application has access to all the exposed Objects in that module. For that matter you can understand, why just adding a some-ng-file.js and including that ModuleName in the dependency of an AngularJS application, gives a lot of ngObject to play with. Where in AMD each module is exposing just one Object. If you want to play with the internals of that Object, you have to call that Object’s properties and methods. This way makes you feel like as if you are working in a Classical (Class based) language rather than Prototypical language. BackboneJS is doing exactly the same thing. Once you have got a BackboneJS module Object, you deal with it as if you are dealing with an Object from a Class. You invoke methods and properties of that Object.

So one Module in AngularJS is exposing a lot to play with and one Module in BackboneJS gives you just one Object to play with. The similarity goes to other frameworks and libraries as I mentioned earlier about DOJO Toolkit and NodeJS.

Happy coding with modules.

25. November 2015

AngularJS 102

This is the part two of the study of AngularJS. The first part is AngularJS 101. This is focused on the vary basic concepts of AngularJS like how and where to write a controller or directive etc. The sample project is here.

First thing first, as of any Javascript framework, the nature of AngularJS is not different in terms of, where you should write what. This is understood, as Javascript itself is dynamic in nature. There are a lot of guidelines through out the web as to, which file to contain what. In the end it boils down to personal preference. So just go ahead and do some working samples of yours.

  • The first thing you need is index.html or some .html file, which will be your entry point to the project.
  • Include all the Javascript files in this index.html file as needed
  • AngularJS does not need JQuery, but if you are using Bootstrap, you will need JQuery library as the later uses it. So include them in the index.html
  • Include the CSS framework files in the index.html
  • All in all, include all the files necessary in the project in index.html

Well, there are ways to minify and combine all of them in a single file and all those tricks. We can focus on them later. For the timebeing lets focus on how to build AngularJS applications.

  • In the end include your application.js file, which will be your application entry file. Name of the file is not relevant, you can name it anything.

All of the application could be written in a single Javascript file or the application could be divided to be written in different Javascript files, each having a particular scope of work. Whatever the case may be, just remember each Javascript file should be an AngularJS module.

(function(){'use strict';
var appModule = angular.module('app.Main',["ngRoute","ngResource"]);
})();

The general convention is to wrap each module inside an immediately invoking function, just not to pollute the global space of the Javascript. As in the example above, we are using ngRoute and ngResource in our module app.Main.

  • Each Javascript file should be an AngularJS Module
  • Each module can use another module as a dependency and that can be passed in as a parameter in the array as shown above
  • By now, you must have noticed, the name of the Javascript file and the name of the module might be different. As long as we provide proper name as dependecy and proper name for the script src, it is all good.

Actually in the example above, the dependent modules ngRoute and ngResource is not present in the angular.js Javascript file . These modules are written in separate Javascript files as modules. So we need to include angular-route.js and angular-resource.js in our .html file to use them, else it will through error.

<script type="text/javascript" src="js/lib/angular-1.4.7/angular.js"></script>
<script type="text/javascript" src="js/lib/angular-1.4.7/angular-route.js"></script>
<script type="text/javascript" src="js/lib/angular-1.4.7/angular-resource.js"></script>

Have a look at the Sample Project. Lets define another module in a javascript file named one.js.

(function(){'use strict';
  var mOne = angular.module('module.one',[]);
})();

Now lets expose a factory from this module.

(function(){'use strict';
  var mOne = angular.module('module.one',[]);
  mOne.factory('oneFactory',function(){
    var service = {};
    return service;
  });
})();

To use this factory in our project. We have to

  • include the one.js in our html file
  • add the module name module.one in our application entry file

So the application entry file will look as below

(function(){'use strict';
  var appModule = angular.module('app.Main',["ngRoute","ngResource","module.one"]);
  // Now, we can use 'oneFactory' here, as its exposed by 'module.one'
})();

Each Javascript file should be an AngularJS module.

  • Each module could expose any number of anything. That means, any module could expose more than one Object. Those Objects could be any AngluarJS Object types, such as Controller, Factory, Service, Directive etc.
  • As long as we are providing a dependency of the module name in the Array and refering the proper name of the Objects, we can use them.

Directives in AngularJS are visual elements. They define custom HTML tags/elements as per their definition.

Take a look at the Sample Project and that should clear a lot of things, which might seem unclear here. AngularJS is modular in the sense, there are carefully separated modules for different purposes. When in need, we include those Javascript files and add the dependecies in the Array. The same goes for our own modules. Try to separate out functionalities into their own modules and use it when needed.

Hopefully that will get you started with the framework.

18. November 2015

A year with DOJO Toolkit.

There are a number of reasons to use a specific framework in a work environment. But sometimes it boils down to just the hype. For example in recent past almost all the companies are trying to implement AngularJS and before that time it was the time for BackboneJS and the story goes on like that. It is always a good experience to work in very different kind of framework or for that matter its even better to work in different kind of languages altogether.

The last year was DOJO Toolkit year for me. I must say I am impressed to see features it provides and now that its moving in the right direction. For a long time now, this toolkit was just stagnant but last year only they have started moving again. Well, if you come from a pure Javascript background might not like it by the way it is designed and behaves. The UI layer of the DOJO Toolkit named as Dijit will seem like Flex components (If you know what Flash and Flex is, you will get what I am saying). The framework itself is designed to make people comfortable, who are used to Classical programming languages like JAVA. The whole toolkit will show itself, as a class based toolkit. The average user will just think and use it as a Classical programming language, which is the root of all evil things in a project. Thats part of the team and how it works with this toolkit.

In general if we talk about the features this toolkit gives us, I would say its nice and efficient if we use it the way it is meant to. The next version is already on progress and they are moving to TypeScript, that a nice move. All in all its a nice experience working with this framework.