EmberJS vs AngularJS : performance testing

Performance testing is really a tough task. If the matter was to compare ember and angular, with their given features, simplicity or number of lines in the code, it really become simple as it atleast has a platform. But measuring performance depends on browser, number of environmental factors, data transfer, type of your app, code quality, logic and much more. And the judgement factors are simply the speed and accuracy. But it’s really a variable thing to judge, as the test cases play their roles.

Today with few chosen test cases I would like to show you the visible difference between ember and angular. How according to implementation cases their behavior changes, how they exactly works and these things will help you to choose the right one between ember and angular  for your application.

Rendering:

Test App Links:

Ember Output: http://jsbin.com/AzaceNo/1/

Angular Output: http://jsbin.com/ucopUca/1/

Ember Editable: http://jsbin.com/AzaceNo/1/edit

Angular Editable: http://jsbin.com/ucopUca/1/edit

Test Objective:

Let’s say I have a lot of elements in my app, which the framework has to render to the DOM. Here I am testing with 10,000 elements.

How To Test:

Open the links of Ember Output and Angular Output, given above. Now Click on the “Render” button of each example and see how much time each of them takes to render 10,000 elements to the DOM. The elements will be displayed once they are rendered to the DOM.

Description:

You will find, to render the elements Ember is taking almost 4 times more duration, than that of Angular. Angular is really fast on rendering. Cause, they don’t put any overheads like observers or something while rendering the elements. But in the other hand, Ember sets observers each time it creates an elements. So due to this overhead Ember is taking more time here.

Data Binding:

Test App Links:

Ember Output: http://jsbin.com/IYAdIVEP/2/

Angular Output: http://jsbin.com/AGIJUmOj/1/

Ember Editable: http://jsbin.com/IYAdIVEP/2/edit

Angular Editable: http://jsbin.com/AGIJUmOj/1/edit

Test Objective:

Let’s say I have a lot of elements in my app, and I want to change some elements with my input text field or in some other ways. The simple data binding which is called. Here I am testing with 10,000 elements.

How To Test:

Open the links of Ember Output and Angular Output, given above. Now type something in the input box. You will see the databinding is really nice with both the frameworks. Now Click the render button of each framework app and let the elements to render. Now try to write something in the input box.

Description:

You will find, in case of Ember the data binding is really smooth and real time. While the Angular one is stuck; or you can say really slow to bind the objects. This is because, while rendering the elements Ember put an observer to each elements. So whenever the value of an element is changed, it directly pings the control and ember handles the databinding very nicely. But as Angular follows the Dirty Checking to find the change, so it has to scan each and every element with its previous value to find whose value has been changed. That’s why Angular is taking so much time.

Operation flow:

Test App Links:

Ember Output: http://jsbin.com/UCuJiH/1/

Angular Output: http://jsbin.com/uTuqOsO/1/

Ember Editable: http://jsbin.com/UCuJiH/1/edit

Angular Editable: http://jsbin.com/uTuqOsO/1/edit

Test Objective:

Let’s say I have 400 objects in my App. And I want to continuously update them. The change will be made to all those elements with a time interval.

How To Test:

Open the links of Ember Output and Angular Output, given above. You will find 400 elements there on each example. Now click on the buttons “Animate with EmberJS” and “Animate with AngularJS”. Look at the animations carefully.

Description:

You will find, the Ember animations are not as smooth as the angular one. This is because, in case of angular, what is does is, it first changes the values of all 400 elements, and after that the $apply() function is called, and the view is changed. But in case of ember, it takes the help of observers. So whenever a value is changed, the corresponding view is also changed. This is similar to call the $apply() function 400 times.

Conclusion:

In my Angular vs Ember vs Backbone also I’ve said that you can never say a framework is good or bad. It all depends on your app. According to the app you have to choose the framework. In case of performance also it’s same. If you have to make the bootstrapping of the app faster, angular may be good, but for quick response among lots of elements ember will go handy. Consider the app’s size, need, response factors, then choose your framework; this is the only way to get great performance.


Still having issues?

If you still have issues understanding the above article, please leave a comment below and we will try to address that. In case you need help in your projects or understanding anything related to Programming; contact me, Paul Shan for assistance. Thank you for being a reader of VoidCanvas.

About This Author

Hello! I am Paul Shan, a JavaScript Expert, Full Stack and DevOps Engineer cum Consultant based out of Bengaluru, India.

  • Lars Schinkel

    Thank you for that! I am genererally carefull in hyping one of these next big thing frameworks like AngularJS or EmberJS. To be honest I don’t completely agree with the time saving benefits of them, because there are more important arguments than time saving and managing objects don’t need superhero frameworks. Sometimes I think, that it’s only cool, because they promise you the world. But you will have problems with them very soon 😉

    Simply to compare your performance samples to jQuery, here is an example:

    http://jsbin.com/ELOziDo
    http://jsbin.com/ELOziDo/1/edit

    • metalshan

      Everything has pros and cons… The main thing is, how smart the user is to use the pros only. 🙂

      And, the example you gave, yes it’s rendering much more faster comparing with Angular or Ember. That is because jQuery is just simply render a simple POJO object to the DOM. But an angular or ember object is not as simple. They have observers, binding handlers and many other things, which takes time to get rendered; but they provide you benefits also. And, basically focusing on those benefits they are developed…
      So, if, one don’t want those features, and his work can be done with simple objects; than ofcours he should go with jQuery.

      And about that time saving factor…. You try to make http://jsbin.com/IYAdIVEP/2 using simple jQuery…. n see how much time it takes to type the code. Then check performance. The frameworks are made to develop big project, not code snippet… So I think, at the end of the day…. it really matters to write less number of codes.
      🙂 🙂

    • Lars Schinkel

      So true … it always depends on your goals. And it’s rather unrealistic, that you will have to write 10000 elements in your DOM. But it’s very interesting to see the difference between the philosophy of AngularJS comparing to EmberJS. I will go ahead learning AngularJS … even if I’m not totally convinced yet 😉

    • metalshan

      Situations may come Lars, Suppose I don’t have a restful api, and in my app I wanna display all the country list of the world in a dropdown. According to the selected country, a state selection dropdown will appear, and so for cities. So in that case it may exceed 10000, you never know you know… 😛 😛

    • Lars Schinkel

      Oh yeah … retrieving an comprehensive list of cities on one … a very good idea^^

  • Tehnix

    “You will find, the Ember animations are not as smooth as the angular one. This is because, in case of angular, what is does is, it first changes the values of all 400 elements, and after that the $apply() ”

    I think you meant to say that *Angular* animations are not as smooth. Ember’s run smoothly, and it’s also Angular you mention that has to go through 400 $apply’s.

    • metalshan

      Oh.. That was a mistyping. Thanks Tehnix for notifying. 🙂

    • micahblu

      Can you please update the post to reflect.. Quite misleading for people looking for valid performance information on these frameworks. Overall great article.

    • Richard Eng

      The typo still hasn’t been corrected 9 months later!

    • metalshan

      Well, I’ve checked the demo and and don’t know if because of the browser update or what the performance difference is not visible in naked eye any more.
      I will put a execution time execution calculator and will update with proper data.

  • RandyB

    This is excellent! One thing I would like to mention regarding bindings slowing down as you get a lot of elements on the page. I have been using AngularJS 1.2.15 and this seems to have been improved quite drastically. There is still a slight delay, but it doesn’t seem to hang.

    Overall, I like how you stressed choosing based off of the needs of your application. When I have a small application, adding the overhead of a MVC client side framework just doesn’t make a lot of sense. For a large application I am working on, we really focused on code maintainability, testability, and development speed and as a result have chosen AngularJS and so far we have not run into any issues.

    • metalshan

      Yaa, Angular is pretty good; even I’ve wrote another article on why angular is better.
      But as you’ve mention the word ‘maintainability’ as a requirement of your project, so I will tell in for of ember. Now, let me describe why with some practical thing.

      Angular is better there is no doubt, but it’s hard to have all good developers in your team. By good developer i’m not trying to address those who know angular, but to them who have structured and maintainable coding skills. You can’t have that kind of people every time in your team.

      In angular you can write your logic anywhere, angular is not only a framework, it’s a HTML compiler. So, the poor developer in your team may write a logic in your template, which he shouldn’t really do; cause after few months when he won’t be there in your team and someone has to modify the code, he has to search in many places.

      In ember, things are very strict. You have to follow the ember way every time, otherwise it just WONT work. So, the poor developer is also forced to write the right code at right place with proper convention. So if some day some other person replaces that previous developer, things will be easier for him to find and modify. This really saves huge amount of time. So generally in maintainable projects I prefer ember.

      But still, angular is also really awesome… You won’t find any problem.. just review the code of your team mates… otherwise it may hrt u in future

  • It’s not EmberJS that makes the rendering slow, it’s Handler bars. I would really like to see the same performance testing with HTMLBars

    • metalshan

      HTMLbars are more compatible with ember. It handles more things from server side. Hope this will help to render the elements faster. I haven’t worked with HTMLbars yet. Will start with this and update you with the performance test demo.

  • Tomcy John

    Very good way of comparing and good to see working examples. I do know that examples here are not real but these are good starting points to see things in action.

    Thanks