Agreed, another aspect that I never understood, and was a problem with Angular 1.0 bindings. At least when doing it in-line, bindings don’t introduce a new flow compared to what a developer’s custom equivalent code would do.
Benoit > On Nov 2, 2015, at 11:35 AM, Brian Chin <[email protected]> wrote: > > Regarding the Polymer 1.0 situation, as a client the new system seems to be > simpler. The core aspect is that now when you modify a property, the > resulting changes propagate instantly. O.o required update callbacks to be > executed on a new microtask after the associated field/item was modified. In > my experience, the instant propagation is easier to reason about for the end > user. > > On Mon, Nov 2, 2015 at 11:31 AM, Benoit Marchant <[email protected] > <mailto:[email protected]>> wrote: > Hi Adam, > > Just sharing my $0.02 : I implemented a two-way binding system in my first > JavaScript framework at Apple in 2007, designed as a layer on top of a > property change observing API, like in Cocoa, and that’s still our design in > Montage today. I’ve never felt the need nor understood why observing changes > on a whole object were useful for bindings, and without measuring, I was > concerned (maybe wrongly) by the performance overhead of doing so. > > Thanks for the update. > > Benoit > >> On Nov 2, 2015, at 10:27 AM, Adam Klein <[email protected] >> <mailto:[email protected]>> wrote: >> >> Over three years ago, Rafael Weinstein, Erik Arvidsson, and I set out to >> design and implement what we believed to be the primitive underlying the >> data-binding system of MDV ("model-driven views"). We prototyped an >> implementation in a branch of V8, then got agreement from the V8 team to >> build a real version upstream, while pushing Object.observe ("O.o") as a >> part of the upcoming ES7 standard and working with the Polymer team to build >> their data-binding system on top of O.o. >> >> Three years later, the world has changed in a variety of ways. While other >> data-binding frameworks (such as Ember and Angular) showed interest, it was >> difficult to see how they could evolve their existing model to match that of >> O.o. Polymer rewrote from the ground up for its 1.0 release, and in that >> rebuilding did not utilize O.o. And React's processing model, which tries to >> avoid the mutable state inherent in data-binding systems, has become quite >> popular on the web. >> >> After much discussion with the parties involved, I plan to withdraw the >> Object.observe proposal from TC39 (where it currently sits at stage 2 in the >> ES spec process), and hope to remove support from V8 by the end of the year >> (the feature is used on 0.0169% of Chrome pageviews, according to >> chromestatus.com <http://chromestatus.com/>). >> >> For developers who have been experimenting with O.o and are seeking a >> transition path, consider using a polyfill such as >> https://github.com/MaxArt2501/object-observe >> <https://github.com/MaxArt2501/object-observe> or a wrapper library like >> https://github.com/polymer/observe-js >> <https://github.com/polymer/observe-js>. >> >> - Adam >> _______________________________________________ >> es-discuss mailing list >> [email protected] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> > > > > > > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
