5 ms·

I've been in this gig for years upon years and I still don't see what's terrible about two way binding. Can someone actually justify it without handwaving stat

I've been in this gig for years upon years and I still don't see what's terrible about two way binding. Can someone actually justify it without handwaving statements like "you'll notice at scale", or red herrings like "Angular is slow"?

Kiro 9y ago
I honestly don't remember since I don't use two-way binding anymore but the last problem I had was something with copying one person in a list of people with inputs from one place on the page to another and things got really messy. Sorry, don't remember the details. :/
chrisco255 9y ago
Side effects and testability. Two way binding is great for simple forms, if you have like a dozen or so variables on a page? Two way binding is awesome and allows you to write very terse code and logic. If you start adding dynamic forms, multiple developers, unit tests, and advanced interactive application logic, then you are left with a spaghetti code mess (with 2-way binding). The problems really creep up when you start adding observables or watchers, which watch a particular variable for changes. If you two way bind a UI element with a controller variable, and then have watchers or observables on that variable...it is now no longer clear what side effects you're triggering as your interacting with that UI element. Wonky things can and will happen to you as your app's complexity grows.
- jbreckmckye 9y ago
  > If you two way bind a UI element with a controller variable, and then have watchers or observables on that variable...it is now no longer clear what side effects you're triggering as your interacting with that UI element. I've heard this argument before, and I really don't get it. Let's say I have an input bound to a model variable. What does that mean? Well, the model is the single source of truth of state. And the user can change it. Sometimes we have derived state, like computeds in Knockout. These are read-only and are not ultimately sources of truth (though they will never contradict non-derived values). In this model, I cannot see what is wrong. Why do you need to reason about the side effects your input triggered? Your input should be bound to something that is a fundamental, atomic, irreducible element of the app state. When it changes, the app changes. You never need to reason about this happening because there should never be a moment where a model changes and the app does not. Excuse me for my naïveté, but it looks to me like two way binding can only cause problems if you are binding inputs to derived values, or if your model is not truly irreducible. In which case, you are knackered before you start: how is your app ever supposed to guarantee consistency of state? If you are writing Angular or Knockout code properly, in my opinion, the data flow should be unidirectional just by dint of using an irreducible model and never manually overwriting a derived value. Just because the template has a two way binding to a model does not mean the data flow is pandirectional. Likewise, one way binding does not guarantee unidrectionality: I am fairly sure you could write a React-Flux app where components emit arbitrary actions in response to state changes. Perhaps this is banned in Redux, though.
  - chrisco255 9y ago
    Input Field <-> Controller/ViewModel field two way data bindings are fine when they are kept simple, as I said in my comment. Two way binding is great for simple web form apps. If all you're doing is pairing a Name input field with a name variable on your controller or viewmodel, you're golden. But having worked on complex dynamic form generators and enterprise apps at scale, I've seen the mess that KO observables and Angular $scope watchers create in practice. Neither KO nor AngularJS actively encourage great patterns for data flow in their architecture design. It becomes all too easy, in some deeply nested directive or KO observable, to reference external/parent context or scope. React was specifically opinionated about this because Facebook hit real problems in production with two way binding. Another benefit of one-way flow is that it becomes trivial to refactor your UI into modular components. Because the data flows in a top down manner passed in as props, it's easy to break up a complex component into several sub components. React encourages you to fall into the "pit of success" by its design and there's very few traps.
- Bahamut 9y ago
  I recommend taking a look at how Angular 2+ does it - the Angular team originally intentionally omitted it, but they found a way to make it work in a technically sound fashion (output changes being evented). The side-effects problem was certainly true with Angular.js - it is not true with Angular.
  - chrisco255 9y ago
    Angular2+ is an improvement, no doubt, and the eventing based system is not unlike React's in that sense. Although it does require you to instantiate an EventEmitter which is somewhat arbitrary. Still, it's a better data flow model overall for sure.
r00nb00m 9y ago
It's pretty much an issue of getting to a "stable" state, which means that model stabilizes to a certain value after all the actions by user and code. That can be a problem with 2way binding and sometimes it causes very subtle bugs, but it boils down to the infamous event storm. So that's why they gave up on 2way binding and made it more optional and deliberate
luord 9y ago
The problem with two-way binding is that people use more than one source of truth and blame that questionable (to not use stronger words) decision on the framework. At least that's what I've seen it come down to.

Kiro 9y ago

I honestly don't remember since I don't use two-way binding anymore but the last problem I had was something with copying one person in a list of people with inputs from one place on the page to another and things got really messy. Sorry, don't remember the details. :/

chrisco255 9y ago

Side effects and testability. Two way binding is great for simple forms, if you have like a dozen or so variables on a page? Two way binding is awesome and allows you to write very terse code and logic. If you start adding dynamic forms, multiple developers, unit tests, and advanced interactive application logic, then you are left with a spaghetti code mess (with 2-way binding). The problems really creep up when you start adding observables or watchers, which watch a particular variable for changes. If you two way bind a UI element with a controller variable, and then have watchers or observables on that variable...it is now no longer clear what side effects you're triggering as your interacting with that UI element. Wonky things can and will happen to you as your app's complexity grows.

jbreckmckye 9y ago
> If you two way bind a UI element with a controller variable, and then have watchers or observables on that variable...it is now no longer clear what side effects you're triggering as your interacting with that UI element. I've heard this argument before, and I really don't get it. Let's say I have an input bound to a model variable. What does that mean? Well, the model is the single source of truth of state. And the user can change it. Sometimes we have derived state, like computeds in Knockout. These are read-only and are not ultimately sources of truth (though they will never contradict non-derived values). In this model, I cannot see what is wrong. Why do you need to reason about the side effects your input triggered? Your input should be bound to something that is a fundamental, atomic, irreducible element of the app state. When it changes, the app changes. You never need to reason about this happening because there should never be a moment where a model changes and the app does not. Excuse me for my naïveté, but it looks to me like two way binding can only cause problems if you are binding inputs to derived values, or if your model is not truly irreducible. In which case, you are knackered before you start: how is your app ever supposed to guarantee consistency of state? If you are writing Angular or Knockout code properly, in my opinion, the data flow should be unidirectional just by dint of using an irreducible model and never manually overwriting a derived value. Just because the template has a two way binding to a model does not mean the data flow is pandirectional. Likewise, one way binding does not guarantee unidrectionality: I am fairly sure you could write a React-Flux app where components emit arbitrary actions in response to state changes. Perhaps this is banned in Redux, though.
- chrisco255 9y ago
  Input Field <-> Controller/ViewModel field two way data bindings are fine when they are kept simple, as I said in my comment. Two way binding is great for simple web form apps. If all you're doing is pairing a Name input field with a name variable on your controller or viewmodel, you're golden. But having worked on complex dynamic form generators and enterprise apps at scale, I've seen the mess that KO observables and Angular $scope watchers create in practice. Neither KO nor AngularJS actively encourage great patterns for data flow in their architecture design. It becomes all too easy, in some deeply nested directive or KO observable, to reference external/parent context or scope. React was specifically opinionated about this because Facebook hit real problems in production with two way binding. Another benefit of one-way flow is that it becomes trivial to refactor your UI into modular components. Because the data flows in a top down manner passed in as props, it's easy to break up a complex component into several sub components. React encourages you to fall into the "pit of success" by its design and there's very few traps.
Bahamut 9y ago
I recommend taking a look at how Angular 2+ does it - the Angular team originally intentionally omitted it, but they found a way to make it work in a technically sound fashion (output changes being evented). The side-effects problem was certainly true with Angular.js - it is not true with Angular.
- chrisco255 9y ago
  Angular2+ is an improvement, no doubt, and the eventing based system is not unlike React's in that sense. Although it does require you to instantiate an EventEmitter which is somewhat arbitrary. Still, it's a better data flow model overall for sure.

r00nb00m 9y ago

It's pretty much an issue of getting to a "stable" state, which means that model stabilizes to a certain value after all the actions by user and code. That can be a problem with 2way binding and sometimes it causes very subtle bugs, but it boils down to the infamous event storm. So that's why they gave up on 2way binding and made it more optional and deliberate

luord 9y ago

The problem with two-way binding is that people use more than one source of truth and blame that questionable (to not use stronger words) decision on the framework. At least that's what I've seen it come down to.