Is Angular.js or Ember.js the better choice for JavaScript frameworks?

Great post from Tom Dale on Ember vs Angular …

Answer by Tom Dale:

As one of the authors of Ember.js, I frequently get asked: "Should I use Angular or Ember?"

I think the answer to that question has a lot more to do with what kind of application are you building? than is Ember better than Angular?

While there are a few superficial similarities—they both use bindings and are more helpful for writing web applications than, for example, Backbone.js—they quickly depart from one another in how they expect you to approach building apps.

Let me first discuss the inspiration for Ember.js. Starting in 2009, I worked on SproutCore while at Apple, in addition to contributing to the suite of web applications that became what you now see on iCloud. In that environment, I was surrounded by some of the best Cocoa developers in the world.

Now, here's the thing about client-side web applications: they're not really breaking new ground. The fundamental model has been around since the 80's: code running locally on a computer, fetching data from the network, and then rendering it locally and putting it on screen. Really, the only thing that's changed is that the code is running inside the sandboxed environment of the browser, and the "binary" is loaded as you need it instead of being installed by the user onto their hard drive.

To me, the obvious thing to do is to look around and ask: What have the people who have come before us done? And I think it's hard to argue with the success of frameworks like Cocoa, both on the Mac and on iOS, in aiding developers in writing apps that users love.

We want developers to be able to build ambitious web apps that are competitive with those native apps. To do that, they need both sophisticated tools and the right vocabulary of concepts to help them communicate and collaborate.

With Ember.js, we've spent a lot of time borrowing liberally from concepts introduced by native application frameworks like Cocoa. When we felt those concepts were more hindrance than help—or didn't fit within the unique constraints of the web—we turned to other popular open source projects like Ruby on Rails and Backbone.js for inspiration.

Ember.js, therefore, is a synthesis of the powerful tools of our native forebears with the lightweight sensibilities of the modern web.

Now, Angular: I actually really like Angular, Google, and all of the developers I've met on the Angular team. In fact, we had once discussed how we might unite our efforts, but—excuse my French—the synergy just wasn't there.

Angular, in my opinion, is much more of a research project than Ember.js. Just look at the terminology: Ember talks about models, views, and controllers. Angular's guide requires you to learn about things like scopes, directives and transclusion.

I am all in favor of research projects, and I wish them the best. But, as Jeremy Ashkenas always says, look at the apps in production.

Big companies have invested serious time and energy in Ember.js, and the results speak for themselves. The new version of ZenDesk has been rewritten in Ember (after they got frustrated with Backbone.js and moved off it). The entire web experience at Square is Ember, because they wanted a beautiful and responsive UI on the web and institutionally know that those can be delivered using concepts borrowed from Cocoa. Many of Groupon's mobile web apps are Ember.js. There are many, many more startups finding success with Ember.js, and in turn, contributing to it and helping grow the community.

The majority of apps that I've seen written in Angular are demos or internal Google properties.

Yehuda and I have been extremely aggressive about getting real users of Ember involved in the design and maintenance of the framework. This keeps us honest and makes sure features we add are not things we think are neat but are driven by real problems developers are hitting today.

In fact, for the past few months, the majority of the work on Ember.js proper has been done by a core group of community contributors, from different companies. If Yehuda and I got hit by a bus tomorrow, Ember would be fine. If our company went under, Ember would be fine. By making this a truly community project, instead of a "by Google" project, I believe we get an order of magnitude more man-hours contributed to it.

Back to technical details. From their own website, "AngularJS is what HTML would have been, had it been designed for building web-apps." I think that that philosophy is evident when looking at their apps. The user interface is defined by HTML tags, decorated with attributes (like `data-ng-repeat`) that have semantic meaning.

Ember.js uses Handlebars to describe the HTML that makes up your application interface. Now, aesthetically, we can argue whether you prefer Handlebars syntax (which uses, for example, the

{{#each}}

helper) or annotating HTML with additional attributes like Angular does. I personally think that the HTML attribute approach is a little noisier and hard to read, but I think that anyone can get used to either one. If Ember.js didn't exist and I had to use a framework that uses data attributes, I wouldn't cry.

But leaving aesthetics aside, I believe that our approach to using string-based templates gives us several advantages, both now and in the future:

  • String-based templates can be pre-compiled on the server. This signficantly reduces startup time (because there is effectively no computation required at app boot) and means that rendering a template is as simple as invoking a function.
  • Angular requires you to traverse the entire DOM at app boot time. The bigger your app is, the slower it starts.
  • If you ever want to render your app on the server (for indexing by Google crawlers or to make first loads display faster), Angular requires you to boot an entire browser environment like PhantomJS, which is resource-intensive. Handlebars is 100% JavaScript strings so all you need is something like node.js or Rhino.
  • String templates are easy to divide up and load lazily, if your app starts getting large.

Additionally, Handlebars only lets you bind to properties, while Angular allows you to embed arbitrary expressions that live update. Many people initially see this as a limitation of Ember, but in fact:

  • Ember.js makes it extremely easy to create computed properties in JavaScript, which can contain arbitrary expressions. We just require you to specify your dependencies so that we can be smart about when we update. Only things that change are updated.
  • Angular must recompute those expressions every time something changes, which means the more bound elements in your app, the slower it gets.
  • Because Ember.js only allows you to bind to properties, we will very easily be able to take advantage of the performance benefits of ECMAScript 6 features like Object.observes (http://wiki.ecmascript.org/doku….). Because Angular invented their own subset of JavaScript with a custom parser (https://github.com/angular/angul…), it would be difficult to allow browsers to optimize this in native code.

Angular, in general, relies on something called dirty checking to determine when changes have been made. Dirty checking is when you scan each object and all of its bound properties, comparing the current value to the last known value. If it changes, you go update the binding. As you can imagine, this gets very expensive the more objects you have.

The Angular guys are smart and they made this tradeoff very carefully. Their reasoning is:

  • With dirty checking, you don't need to use accessors. You can say
    person.name = "Bill"

    instead of

    person.set('name', "Bill")

    like you would in Ember.js or Backbone.js.

  • Why would you ever have so many objects in DOM that this would end up becoming a bottleneck?

Needless to say, we made the opposite decision. Miško Hevery describes the tradeoffs they made on StackOverflow: http://stackoverflow.com/a/96939….

He points out, with dirty checking, that you can never have more than 2000 bound objects at a time. (Note that only one of his three "issues with change listeners" applies to Ember.js, because of our run loop.)

I think that this illustrates best the difference in philosophies between Ember.js and Angular. Ember.js and Angular both strive for simplicity and ease-of-use. But Ember is designed so you don't have to worry about whether or not you have 2000 bindings. If you're writing large-scale apps, you've got bigger things to worry about.

Angular is great for small- to intermediate-scale applications that will never run into the limitations of their architecture. With Ember, we sometimes ask you to do a little more work—like specifying the dependencies of your computed properties—in order to make the most common operations run at O(1) instead of O(n), or worse.

We're always looking to take advantage of new browser and language features to make things easier to use. For example, once proxies land in ES6 (http://wiki.ecmascript.org/doku….), we won't require you to use

get()

and

set()

any longer. But we're not willing to give you a little bit of rope if we think you'll just end up hanging yourself with it as your app grows.

So that's why I think, if you're building ambitious apps, you should pick Ember.js.

We're not afraid to borrow liberally from our predecessors that have already learned how best to build large apps.

We've got a fantastic community that has some of the smartest web developers working on the hardest problems, and they're doing it because they're hitting those hard problems in the real world and they want to solve it correctly.

We've thought very long and very hard about performance, how to make sure your applications don't hit pathological cases, and how to best take advantage of the features coming in the language. (Yehuda Katz, who works on Ember.js with me, is also on on TC39, the committee in charge of coming up with the next version of JavaScript.)

We've now locked down the 1.0 API, so you can start learning and not worry about the ground changing from under your feet.

To really get a feel for Ember, here's a screencast I put together of building an app from scratch:

http://www.youtube.com/watch?feature=player_embedded&v=Ga99hMi7wfY

There are also some great resources for learning:

If you're building ambitious apps, you should definitely check out Ember.js.

Is Angular.js or Ember.js the better choice for JavaScript frameworks?

Are there any places in India that look like Europe?

Answer by Rahul Khanvilkar:

Big Ben, London

Rajabhai Tower, Mumbai


Arc de Triomphe, Paris

India gate, New Delhi


Leaning Tower of Pisa, Italy

Qutub Minar, New Delhi


Trakai Castle, Lithuania

Jal Mahal, Jaipur


Venice, Italy

Alappuzha, Kerala


Switzerland

Shimla, Himachal Pradesh


Oresund bridge, Sweden to Denmark

Bandra Worli Sea Link, Mumbai

Are there any places in India that look like Europe?

What are some facts about Facebook, Google, and Twitter that not many outsiders know about?

Answer by Ashish Sharma:

The Facebook notification icon which is globe shaped changes its map view with your location.
  • access Facebook from the US and countries in Latin America:

  • And this is the icon for countries in the Eastern hemisphere:

Quoted from the source:
"It’s the small things in life that can make a difference, and this is a nice way to acknowledge that Facebook is a global service, not just from the US."

reference:
TIL: Facebook's Notification Icon Varies Worldwide

What are some facts about Facebook, Google, and Twitter that not many outsiders know about?

What are some of the best roads/routes in India?

Answer by Pranav Kulkarni:

If you discard the tourist in you and embrace the life of a traveler, you tend to find beauty in the journey instead of the destination. Having traveled across 11 states in India, most of them on 2 wheels, I've come across some beautiful roads…

Listing some of my favorites:

1. Stuck in snowfall at 12300 feet, Manali – Leh highway

2. NH 212, passing through the Bandipur forest en route Ooty

3. When the colossal mountains make you feel insignificant, Manali – Leh highway

4. The blue sky and blue water providing a surreal experience

5. NH 21

6. NH 1D, The road disappearing into the horizon, en route Kargil

7. Mahabaleshwar, a popular tourist place in Maharashtra

8. One of the high altitude passes on the Manali – Leh highway

9. Manali – Leh highway

10. Typical Konkan roads

11. Find the river, find the road

12. Early morning on the road meandering through coffee plantations in South India

13. NH 222, as straight as it gets

14. The twisty descent from Rohtang top

15. A coastal road in Konkan

16. The deep woods of Dandeli forest, Karnataka

17. World's second highest pass, 17582 feet

18. Anjarle Beach viewpoint

19. Somewhere on NH 21

20. A random road in the Western Ghats (notice the fog, you can see the light of the vehicle at the end)

21. NH 1D, everybody loves curves

22. Paradise on Earth, Kashmir

23. When good or bad roads mean nothing, it's the view you enjoy

24. The scariest road I've encountered, Zozila pass

25. NH 4, for the ones who don't believe India has good roads

Note: all the pics have been clicked either by me or Rohit Mohite. No watermarks, no trademarks, you can use them as wallpapers if you like them. Hope you like them!

What are some of the best roads/routes in India?

Which is the most beautiful state in India?

Answer by Jubanashwa Mishra:

First I thought it's Kerala, when I spent a night in Alleppey boat house

But soon it changed to Tamilnadu, when I saw the greenish water of Rameswaram

Then Karnataka, when I saw the beautiful Mysore palace

Then Andhra Pradesh, when I look at the Tirupati temple

Telangana, When I did boating inside the Hussain Sagar Lake, Hyderabad

Then Odisha, when I had Mahaprasad at Puri Jagannath temple

Then Jharkhand, @ Hundru Fall

Then a bigger fall at Chitrakote, Chattisgarh

My quest for waterfall ends at Dhuandhar, Madhya Pradesh

West Bengal became my favorite when I enjoyed Durga Puja of Kolkata

Gradually I entered into the north east, fell in love with Sikkim

This is what I was looking for @ Tawang Monastery, Arunachal Pradesh

Fell in love with Nagaland once knowing about Horn Bill Festival

Then Manipur, once I learnt about world war II cemetery, Imphal

Then Mizoram when I saw the beautiful churches

Then Tripura when I travelled in a meter gauge train

Meghalaya, when I came across the village Mawlynnong

I enjoyed the fish through out Assam, Thanks to Brahmaputra river

Fell in love with peace when I reached Bodhgaya, Bihar

Uttar Pradesh became my favorite, After seeing Ganga Aarti in Varanasi

Soon it changed to Goa, Once I came across the the beautiful beaches

Then Maharashtra once reached the maximum city, Mumbai

Then Gujarat once looking at the mesmerizing Rann of Kutch

Rajasthan became my favorite when I looked at the beautiful palaces

Haryana I got to know the root of Mahabharata at Kurukshetra

Punjab when I saw glittering sarovar of Golden temple, Amritsar

Uttarakhand when I passed by the serpentine trail of Mussorrie

Himachal, When I reached top of the Triund Hill

Finally when I crossed miles to reach Leh Ladakh, Jammu & Kashmir: I already realized that the whole India is beautiful, not just any single state.

Which is the most beautiful state in India?