AngularJS Vs EmberJS
One of the battles we are seeing the developers fight these days has been for the Throne of JS framework. The interwebs keep fighting these wars and in the end there is never a proper victor. But still we persevere because that is the nature of humans. The contenders in this particular war are Backbone, Ember & Angular ( there are other smaller colonies but for this discussion and for the sake of brevity we shall leave them out ). . Alteast, these are the 3 most popular MV* javascript client-side frameworks according to github watchers.
This post is not mostly about Backbone because a lot of people have already discussed it at length, come to various conclusions and moved on. Even the inspiration for this blogpost compares Backbone with Ember. I myself have written a longish answer on StackOverflow about the topic.
Disclaimer : I have never worked with EmberJS. So you might deem that I am not the proper person to talk about this. Continue at your own risk.
This post is really a response to what the inspiration talks about. This is a response based on what I managed to assimilate based on that post. So lets begin…
Backbone and Ember
To set things straight first, after having gone through that post, one thing was clear to me. Ember apparently does , in fact, do more ( much, much more! ) than what Backbone does for any developer. One of the toughest things to do, when starting a project, is making choices. Ember takes care of that for you. It has already made choices and it has already prescribed those choices to you, which means that there is “an Ember way” of doing things. You stray from this god-chosen path and you are left to yourself.
Backbone on the other hand does not make any choices for you which means that you have freedom to choose. Freedom means that you are in fact wasting quite a lot of time making these choices yourself ( and in the end taking responsibility for those choices ). One thing we have to remember is, the average developer out there is like a sheep. He will never know the boundaries of the grazing field. This means that giving him more freedom will eventually lead to him going astray and never knowing that he actually did. Even in restricted environments, you can do mistakes but lets just say that the chances are less. You would argue that , if there is a lot of freedom, the average developer will be more careful. Yes, he would be when he has infinite time and not when there is a manager behind his back pointing a gun to his head. So, restrictions are good. In fact, they are a blessing. Atleast now you can blame the framework.
Does Backbone have two way data binding? No. Ember does.
Does Backbone have composed views? No. Ember does. In fact backbone has no idea about your DOM. You are left on your own when it comes to DOM.
Does Backbone have a complex model structure ? No. Its model structure is the simplest possible. Its “observe” mechanism arises out of setters and getters that are defined on the base Backbone Model Class. Ember does have a mechanism for declaring complex model structures. It has a totally separate module (Ember Data ) to take care of that.
So far we have established that Ember is in fact a far superior choice to Backbone. Now lets try and take apart Ember, shall we?
Language
Ember is / has been put together with a lot of thought behind it. One of the major things that I noticed when going through trek’s post was that Ember used concepts like Ember.Object.extend(…). If you notice what is being done here, you will understand that we are trying to bring into a language a concept that it refuses to bring in. A class. In fact it explicitly calls it a class ( Note the use of reopenClass ).
As opposed to this, angular uses a concept that defines javascript. Its prototype chain. It uses a $scope and each scope you create, prototypically inherits from its parent scope all the way upto the RootScope. Most of your activity is done on this object. There is no confusion regarding “this” because you dont really have to use it in most cases.
Data-binding and polluting the views
This is one of the most infamous complaints I have heard of in terms of what Angular / Knockout do to the HTML. In the name of 2 way data binding, they pollute the beauty, the sanctity of HTML and add their own shit in between. In terms of templating systems, there are two kinds. DOM templates and String Templates. These string templates take strings , take the data and combine them together and produce a pure html which is then pushed into the DOM. To those who talk about the pureness and sanctity of HTML / views, I have a few questions. Why the f**k do you really care about it? What you should be caring about is your productivity and how it looks / appears to your user. Lets say you do have some valid reasons. Have you had a look at the code you have to write to produce these templates in handlebars, mustache, underscore or jqtemplates? They are all ugly as shit and even worse. Just to add, computed properties do exist in Angular as well.
Composite Views
How do both the frameworks compare in terms of Composing views and nesting views inside of each other. As far as my understanding goes, Ember has a way of defining these using outlets (with names if you need multiple ). In your handlebars templates you define outlets which can further be installed into the current view as and when required. Swapping and replacing of these outlets is the way to go if you are into Ember. Angular, since it does everything with HTML itself and calls itself Enhanced HTML provides you more attributes that are self-explanatory. If you see an attribute called ng-switch or ng-repeat what comes to your mind? Yeah, you are right. They both are responsible for exactly what you thought.
This is how you define a repeated element in handlebars / ember<code><script type="text/x-handlebars" data-template-name="contributors"> {{#each person in controller}} {{person.login}} {{/each}} </script></code>
This is how you do the same thing in angular
<code><span ng-repeat="person in persons">{{person.login}}</span></code>
Which do you think is cleaner? Ofcourse, in the final rendered html the ember way above is going to look cleaner because all the other stuff is going to get stripped out. In case of angular, all of this (except the thing in double flower brackets ) is going to stay. But, seriously, who is having a look at your final rendered HTML? Just so you know, that who script tag is going to still exist in your final HTML too , but somewhere else.
DOM Manipulation / the ugly part of client side coding
Whether you agree or not, manipulating the DOM is the most ugly part of writing code in JS. By now most of us are so used to it that it has become part of our life, part of the way of our thinking about DOM. Ofcourse, just to encourage you not to do it, IE / M$ had put in all kind of hurdles in front of you and earlier not many tried crossing that barrier. Finally, one day a great leader ( JQuery ) came forward and showed you a way of crossing the sea ( They even parted that sea for you so you can cross) you are now so accustomed to this life across the sea. What if I told you that you can achieve all the things you have been achieving after getting access to these new tools WITHOUT using them? Ofcourse, you still need those new resource. But, use it only when its absolutely necessary. Not everytime.
Component Architechture.
Ember does not provide you a component architecture. It does not provide you a way of defining new components. It helps you define views , even composite ones but that is not one and the same. Angular’s directive mechanism though agreeably raw currently allows you to provide powerful layouts and widgets. This provides a mechanism for defining terse html code that makes more sense to the reader. It also makes it easier to partition tasks. You can have a component writer and a layout builder – 2 different people doing different tasks they have expertise with. We could even have an open source project which provides you those controls out of the box which anyone can plugin (just like jquery plugin’s but this one is used declaratively! ).
Dependancy Injection
This is something new in the world of JS. As far as I can tell, not many ( I don't know of one that has DI ) have implemented DI in JS. I will be bold enough to declare that Angular is probably one of the only mainstream framework to implement DI. I am not even going to talk about DI in Ember because it doesn't seem to exist. Those who are new to this system seem to find this to be totally absurd or magic. How can it work? Do we declare everything as global and then input those global variables into these controller functions for the heck of it? Apparently not.
DI makes it extremely easy to manage dependancies. There is a central system (which perhaps is global) that when asked for an object of a particular type gives you that object. What do you do in a typical scenario of OOP. If A has a dependency on B, you try to figure out what is the best way of getting B into A. Sometimes you do that communication through events, sometimes through an interface etc. In DI , A asks the DI system for B and the DI system gives it back. But now the question is ,how does the DI system know what to give back? This is done when A or B is created. They register themselves with the DI system with a Unique Name. Lets say DI has an internal map which has a mapping between the name and the Object / Class to instantiate. So whenever you do a DI.give(“A”) it instantiates this A and gives you back that A.
Conclusion
In Conclusion, it looks like Angular provides you with whatever Ember is providing and more. It also has a smaller footprint ( 25kb vs 37kb), reduces even more boilerplate than what Ember does ( remove all DOM Manipulations!). Just to note: Ember is not done yet because they haven't hit 1.0 yet. So we still need to know how they evolve. But it looks like it was created for large applications and helps manage more things than Backbone does, I would even call it an opinionated Backbone on steroids but I don't see it touching the levels of Angular. I don't say this out of malice towards Ember but because angular is showing itself to be a class apart. It dared to think differently and that paid off.
Which do you think is cleaner? Ofcourse, in the final rendered html the ember way above is going to look cleaner because all the other stuff is going to get stripped out. In case of angular, all of this (except the thing in double flower brackets ) is going to stay. But, seriously, who is having a look at your final rendered HTML? Just so you know, that who script tag is going to still exist in your final HTML too , but somewhere else.
DOM Manipulation / the ugly part of client side coding
Whether you agree or not, manipulating the DOM is the most ugly part of writing code in JS. By now most of us are so used to it that it has become part of our life, part of the way of our thinking about DOM. Ofcourse, just to encourage you not to do it, IE / M$ had put in all kind of hurdles in front of you and earlier not many tried crossing that barrier. Finally, one day a great leader ( JQuery ) came forward and showed you a way of crossing the sea ( They even parted that sea for you so you can cross) you are now so accustomed to this life across the sea. What if I told you that you can achieve all the things you have been achieving after getting access to these new tools WITHOUT using them? Ofcourse, you still need those new resource. But, use it only when its absolutely necessary. Not everytime.
Component Architechture.
Ember does not provide you a component architecture. It does not provide you a way of defining new components. It helps you define views , even composite ones but that is not one and the same. Angular’s directive mechanism though agreeably raw currently allows you to provide powerful layouts and widgets. This provides a mechanism for defining terse html code that makes more sense to the reader. It also makes it easier to partition tasks. You can have a component writer and a layout builder – 2 different people doing different tasks they have expertise with. We could even have an open source project which provides you those controls out of the box which anyone can plugin (just like jquery plugin’s but this one is used declaratively! ).
Dependancy Injection
This is something new in the world of JS. As far as I can tell, not many ( I don't know of one that has DI ) have implemented DI in JS. I will be bold enough to declare that Angular is probably one of the only mainstream framework to implement DI. I am not even going to talk about DI in Ember because it doesn't seem to exist. Those who are new to this system seem to find this to be totally absurd or magic. How can it work? Do we declare everything as global and then input those global variables into these controller functions for the heck of it? Apparently not.
DI makes it extremely easy to manage dependancies. There is a central system (which perhaps is global) that when asked for an object of a particular type gives you that object. What do you do in a typical scenario of OOP. If A has a dependency on B, you try to figure out what is the best way of getting B into A. Sometimes you do that communication through events, sometimes through an interface etc. In DI , A asks the DI system for B and the DI system gives it back. But now the question is ,how does the DI system know what to give back? This is done when A or B is created. They register themselves with the DI system with a Unique Name. Lets say DI has an internal map which has a mapping between the name and the Object / Class to instantiate. So whenever you do a DI.give(“A”) it instantiates this A and gives you back that A.
Conclusion
In Conclusion, it looks like Angular provides you with whatever Ember is providing and more. It also has a smaller footprint ( 25kb vs 37kb), reduces even more boilerplate than what Ember does ( remove all DOM Manipulations!). Just to note: Ember is not done yet because they haven't hit 1.0 yet. So we still need to know how they evolve. But it looks like it was created for large applications and helps manage more things than Backbone does, I would even call it an opinionated Backbone on steroids but I don't see it touching the levels of Angular. I don't say this out of malice towards Ember but because angular is showing itself to be a class apart. It dared to think differently and that paid off.
No comments:
Post a Comment