EmberJS vs AngularJS : performance testing

Mon Dec 23 2013

Paul Shan

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.


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.


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.


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.


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.


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.


Today everyone knows the importance of a lightning-fast website and how the speed impacts the conversion rate of a business. Today, everyone wants the site to be a PWA so that the mobile users can have an app-like experience with the website because, for the majority of the merchants, the customers come through mobile devices.
Tue Apr 20 2021
Here we are going to see how you can manage backup and restore of Postgres database with docker.
Thu Sep 03 2020
Image sliders or carousels always have increased the UI attraction of websites and they are pretty useful for reflecting the major roles/products too. In case, I am having a website that sells tee-shirts,
Mon Apr 30 2018

About VoidCanvas

This blog was created out of hobby and talks mostly about technology, web development, JavaScript, NodeJS and related topics. Thank you for reading my blog.

Copyright 2022 - www.voidcanvas.com

Popular Articles

Authentication using Google's oAuth api with node.js

Thu Mar 10 2016

OAuth authentications are pretty popular now a days and another thing which is popular is JavaScript. This article shows how to plugin google’s oAuth api for authentication in your own node application.

CSS3 Loader Snippet Collection: (Part 2 - Squares)

Sat Mar 01 2014

This is a continuation of my CSS3 loader snippet collection series. I've provided spinning css3 animation loader in the part 1 of this series and here in part 2, I'm providing various square type loading