

AngularJS change detection – draft - porker
https://docs.google.com/document/d/10W46qDNO8Dl0Uye3QX0oUDPYAwaPl0qNy73TVLjd1WI/preview?sle=true&pli=1#heading=h.xgjl2srtytjt

======
pavlov
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.

~~~
SchizoDuckie
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.

~~~
latchkey
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](https://github.com/jsog/jsog)

I'm kicking myself for not picking this up earlier.

~~~
caitp
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:

The repository is at
[http://github.com/caitp/watchtower.js](http://github.com/caitp/watchtower.js),
and will probably be moved into the angular org once it's a bit more fleshed
out.

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](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.

------
stephen
Interesting that Misko himself implemented this in AngularDart _first_ , and
then is going to backport to JavaScript.

~~~
saurabhnanda
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).

------
haberman
Anyone know why real Object.observe() seems to be somewhat stalled? I read
somewhere that it had slipped to ES7 -- anyone know why?

~~~
caitp
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.

------
saurabhnanda
Can anyone explain why/how the following statement is true?

    
    
        We can then change the slow field read from current.obj[current.field] to current.getter(current.obj) which triples the performance.

~~~
SchizoDuckie
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.

------
craigching
Is there any more context to go with this? Definitely looks interesting. How
does this compare to FB's React?

------
brokenparser
...but not harder and stronger.

