10 ms·
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
by blissofbeing 13y ago
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 http://emberjs.com/api/classes/Ember.Observable.html
- fivetanley 13y agoWhile 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.
- ebryn 13y agoActually, 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.