How does two-way data binding differ from simple auto-sync?

Question

The AngularJS documentation mentions that it considers one-way data binding to be 'bad' and two-way data bind to be 'good*'. However, on looking over the definitions of two-way data binding used, all it seems to be is an auto-sync put in place between the view and the model.

Diagram

Two-Way Data Binding

Surely this has a performance hit and uses additional resources. Or am I missing something? Is two-way data binding something more than an MVC auto-sync, and are there any aspects of data binding theory which would cause two-way data binding to always be preferable, as seems to be implied in the documentation and diagrams?

*it does this with sad and smiley faces instead of words, as can be seen above...

• Eric King: Can you explain what you mean by "an MVC auto-sync"? That would help us answer the question as to whether it's the same as two-way data binding.
• Guy Incognito: @EricKing That the model (data) and the view (what the users sees) are automatically synced by the controller (the thing that makes the changes).

Answer 1

From the documentation, I am assuming that by "most templating systems", they are referring primarily to server-side templates which get rendered into a view. I feel comfortable making this assumption due to a later statement explaining why angular is different: "... the template ... is compiled on the browser. The compilation step produces a live view." And also because other client-side MVVM / MVC / MVP (aka MV*) libraries offer a similar two-way binding.

For server-side templating, it is not usual for it to be a "live view", because the view is actually rendered on the server instead of the browser. This essentially makes server-side binding one-way. The client must submit changes. Then the server recomputes binding values and renders a new view from those values. I'm not only talking about traditional form-based pages. This applies equally to frameworks which asynchronously load view partials which are computed on the server.

In angular, the model and controller live alongside the view. So, when the user changes a view value, it is pretty immediately changed on the model, and the controller can react to that change... recalculating computed values, loading related data, etc. But again, other client-side libraries are capable of this.

I would say that the terminology is not great here, because angular internally has one-way and two-way binding on directives. This confuses the issue a bit. But for directives, it more amounts to whether the model property is exposed as read-only (one-way) or read/write (two-way). (There's slightly more to it than that, but that's the gist of it.)

Update

So it seems to me that this page is more targeted at something like ReactJS, although it could apply to server-side techs as well. Here is an interesting (biased) article further discussing one-way vs two-way binding. (React is one-way.)

• Guy Incognito: "the model and controller live alongside the view [...!] client side[.] [...] [T]he model [(]property[)] is [(]exposed as[)] read-only (one-way) or read/write (two-way)"

Answer 2

I would be cautious about simplifying what goes on under the hood of Angular.js to MVC, as there have been countless discussions about what MVC even is, and whether Angular implements MVC or MVVM or some other MV* paradigm. It's kind of become accepted in the Angular world that they implement Model-View-Whatever and leave it at that.

Having said that, the two-way binding portion is pretty simple. It's just the portion of javascript that ensures that the html elements of the view and the javascript model remain in sync on the client. As the model changes, the view is updated, and as the view is changed the model is also updated, on the client, in near real time.

This is as opposed to one-way binding, which takes what the model provides and applies it to the view, but changes to the view do not update the model (without a round trip back to the server).

For a client-side library like Angular, it's pretty easy to see how two-way data binding is good, as it is the basis for real-time interactive web pages. Many page elements can depend on the model state (via two-way binding) for their rendering, and as that model state changes in response to some portions of the view being manipulated, other portions of the view may also be updated. With one-way binding, that wouldn't be possible.