Hacker News Reader

> EvilTrout obviously wants to see Ember succeed, I would to if I spent so much time writing a big Ember app and see it loosing out in the Javascript framework wars.

If I chose my languages or frameworks based on what was the most popular, I'd be using Java or PHP, not Ruby and Javascript.

Additionally, Object.Observe benefits Ember just as much as it does Angular.

Wait, are you saying you choose Angular for non super simple stuff? Because I couldn't even consider it due to it's lack of nested layout and routing for anything beyond something super simple.

https://github.com/angular-ui/ui-router

https://github.com/angular-ui/ui-router/wiki/Nested-States-%...

Is that sarcasm ?

I was saying yes to his last question "...do you want to add powerful features and maintain it well over time?"

I find the concept of directives one of the most powerful and maintainable features of any framework I have ever used. It's probably the "killer feature" of Angular.

Yehuda Katz is on TC39, I'm pretty sure that Ember will be well-posed to take advantage of innovations in JavaScript as they happen.

You didn't really rebut anything in his post, just asserted that Angular is 'forward-looking.' EvilTrout makes very specific claims, as someone quite familiar with Angular, you're well-poised to give a real answer, not just chest-puffing.

This may be true, but still Ember forces you to use uses get() and set() while in angular you can just use plain old javascript objects. Basically Angular does dirty checking to keep track of changes while Ember knows of your changes because you are using get() and set()(1).

In my opinion this sucks. I love being able to use plain old javascript objects in Angular. Not having to extend every object with ember.observable is a big win for me. When O.o lands Angular will be just as fast (if not faster) as Ember but without the need to instantiate new Ember objects, and always use get() and set() on them.

Of course Ember could change its API in the future, but Angular won't need an API change because its already using plain old javascript objects.

1: http://emberjs.com/api/classes/Ember.Observable.html

While Object.observe will be a welcome change, that basically means that your app can never be as performant as possible due to the design of the framework that you use for browsers that don't support Object.observe (dirty checking is NOT optimal). Using .get and .set so that all operations happen in a run loop seems like a small price to pay.

While I'm with you and love being able to write my own simple classes and POJOs, ultimately I'll value being able to support users who won't or can't upgrade their browsers.

Actually, it doesn't "force" you to use get/set. You can just POJOs just fine w/ Ember, but you won't get property observation or unknownProperty support.

I also question your assumption that Object.observe will be as fast as Ember's observation system. I wouldn't be surprised if it was several times slower.

Object.observe also doesn't support array observation, which is something we support in Ember.