3 ms·

I talked with one of the devs at BackboneConf (Vojta) and this project started as a 20% project that became fulltime for 3 devs. Apparently a team had been work

I talked with one of the devs at BackboneConf (Vojta) and this project started as a 20% project that became fulltime for 3 devs. Apparently a team had been working on an internal project for 3 months and there was a bet that it could be rewritten in two weeks, which was won. Google uses it for a few internal apps. Of the KVO frameworks, I consider it closest to Ember in the focus on bidirectional bindings for dom/model isolation. The most unique feature of Angular is the change detection technique. Most frameworks handle this via extension of a base object and using get/set functions or ES5 accessors. Angular actually walks the entire model graph on demand. This allows it to work with base JS objects (there's no special syntax to learn) and third party libraries at the cost of having an O(n) operation in the system. The assumption is that modern JS engines are fast enough to do 10s of thousands of checks without a noticeable impact and your client side model is most likely under this size.

ericclemmons 14y ago
Interesting you mentioned Ember, which I'm a fan of as well as Angular, though I've been using Angular almost exclusively for severa weeks. One key difference for Angular is that your markup ends up pretty much exactly how you want it. Ember had <script> tags littering my DOM for binding purposes, which made progressively enhancing forms (and leaving the standard submit event) require manual cleanup prior to letting the page change. To Ember's credit, it is refreshingly opinionated, and solves the very difficult problem of handling complex states and transitions to deep portions of the app.
- damncabbage 14y ago
  Ember had <script> tags littering my DOM for binding purposes, which made progressively enhancing forms (and leaving the standard submit event) require manual cleanup prior to letting the page change. I'm familiar with the <script> tags it dumps for binding, but I don't understand why you needed to manually clean them up. Could you elaborate a little, please?

ericclemmons 14y ago

Interesting you mentioned Ember, which I'm a fan of as well as Angular, though I've been using Angular almost exclusively for severa weeks. One key difference for Angular is that your markup ends up pretty much exactly how you want it. Ember had <script> tags littering my DOM for binding purposes, which made progressively enhancing forms (and leaving the standard submit event) require manual cleanup prior to letting the page change. To Ember's credit, it is refreshingly opinionated, and solves the very difficult problem of handling complex states and transitions to deep portions of the app.

damncabbage 14y ago
Ember had <script> tags littering my DOM for binding purposes, which made progressively enhancing forms (and leaving the standard submit event) require manual cleanup prior to letting the page change. I'm familiar with the <script> tags it dumps for binding, but I don't understand why you needed to manually clean them up. Could you elaborate a little, please?