My experience with Cocoa is that "change detection" (called "key-value observing" in Obj-C land) is a bit of a wild goose chase.
At a distance, the notion seems appealing. But when you try to build anything larger than a simple form UI, you start to realize that maybe it's not such a good idea to have anyone, anywhere, listening to changes on any old property and doing who knows what.
There are two problems with automatic change notifications: timing and context. Usually there is a something else (e.g. a controller) that is actually doing the property change on a model object. This controller is much better positioned to inform others about the change than the model itself. The controller knows the context, and it can decide whether the notification should go out instantly or perhaps after a bunch of other stuff. The controller can also make this context information available to the listeners, which is often invaluable... But a plain old "this key just changed, ho hum" doesn't let you do any of that.
Then you should really look more into how angularjs works.
The whole thing works so beautiful because there's a global digestion cycle which captures all the changed events within one 'loop', processes the changes, and then kicks off the next cycle, like with a game's heartbeat.
Also, the way you need to set up things with angular makes sure this works perfectly. you need to work with models, controllers, services and directives, which all have a well thought out way of accessing, watching and broadcasting changes.
Things start to break when you start using jquery and just randomly do shit with the DOM outside of angular's scope, but that's one of the reasons why i'm rewriting stuff to work without jquery.
I think angular is the best way forward for the web since the invention of XHR requests actually.
I can't agree more. I'm just now rewriting a portion of my webapp to be a single page app using angular. I'm blown away at how it simple it is to do some really complicated stuff. This is entirely the result of how it forces me to properly organize my code. For example, when I open up a bootstrap tooltip/popover, I wanted to disable all the buttons on the page. It was as simple as invalidating the ng-form and this just works across many directives and modules (assuming you pass the form through the scope). Doing this the old way with jquery would have been a nightmare.
At first I resisted the templates. I kept trying to use Handlebars to render things cause that is what I was used to. Then I realized that the 2 way data binding (ng-repeat with track by) is just magical. I can take a json blob received from an ajax call and set that on a property on the scope. My template just magically updates only the dom elements that changed. By the way, coffeescript is perfect for the templates because you can just embed them in """ ... """ blocks.
My code is also now organized so much more cleanly. The way directive components are organized forces me to think about reuse. It makes it so much easier to see the dependencies between things and create distinct levels of separation. This allows you to make components that can be moved around easily in case you change the flow of your application or just want to display something on another screen.
My buddy and I came up with a way of taking large cyclical object graph blobs of json and de-duplicating the objects for transfer over the wire. This ends up working perfectly with the aforementioned data binding to minimize the amount of json on the wire, while still retaining our complete object model. https://github.com/jsog/jsog
I'm kicking myself for not picking this up earlier.
I'm glad you're finding Angular is working well for you!
You may be (okay, considering what this article is about, you probably are) aware of this, but we're making an effort to drastically improve the performance of the dirty-checking algorithm. Miško wrote a draft paper (you know this, I know) regarding the dirty-checking implementation, and there's an implementation of it in Angular.dart.
I've been working on porting the Angular.dart implementation over to ES6 for the next iteration of AngularJS over the past couple of days, and it's actually pretty challenging, so I'm reaching out to people who are interested for help:
Some things I'm looking for is assistance in improving the tests, and implementing a high quality performance test, possibly using our benchpress library (http://github.com/angular/benchpress). I also would greatly appreciate hearing from people who are a bit more involved/experienced with ES6 might be able to offer some suggestions on how to organize the code, because Dart does not translate 1:1 into ES6, so some help there would be a big deal.
Anyone who is interested in contributing in some fashion, please, you're more than welcome to. We want AngularJS 2.0 to be super-fast, and the more help with this, the better.
Also : Angular.element is really powerful. I'm using it in my chrome extension to parse both RSS and HTML and return objects. Services are an amazing way of working. The web is really my API now.
I think it's useful for rapid prototyping; the developer doesn't need to explicitly define change firing if the change sets are small and easy to handle on a key-by-key basis.
It would be nice if the framework allowed for both paradigms in a clean way. A developer should be able to quickly and safely insert indirection into the change event firing process later in development as an optimization.
At some point you do need some separation between watched bindings and pure logic, that's what the services are for. And quite often people are going to violate those principles of separation until they find out it's a really bad idea.
However the fact that it can be done wrong and get someone into trouble doesn't change the fact that data-binding between the controller and the view is also very useful.
Ouch! I was dreading this from the day AngularDart was announced. I don't want AngularJS to be a second-class citizen within the Angular world -- my startup now depends on it!
Btw, what's the benefit of Dart? I never really understood (or bothered to find out, for that matter).
I'm not seeing it in the latest Harmony draft, but it is already available in some implementations, and polyfills tend to have it.
(one of) The issue(s) which is coming up for us WRT O.o is that current implementations don't seem to work well with computed properties (IE es5 getter/setter functions), which is possibly a point of contention in the draft. Better to ask someone who is seriously paying attention to that stuff, though.
My guess would be that the array access method first parses the whole object as an array, breaking optimisations made possible with JIT compiling, whereas getters and setters are preoptimized because they're the actual standard way of accessing object properties.
At a distance, the notion seems appealing. But when you try to build anything larger than a simple form UI, you start to realize that maybe it's not such a good idea to have anyone, anywhere, listening to changes on any old property and doing who knows what.
There are two problems with automatic change notifications: timing and context. Usually there is a something else (e.g. a controller) that is actually doing the property change on a model object. This controller is much better positioned to inform others about the change than the model itself. The controller knows the context, and it can decide whether the notification should go out instantly or perhaps after a bunch of other stuff. The controller can also make this context information available to the listeners, which is often invaluable... But a plain old "this key just changed, ho hum" doesn't let you do any of that.