Two way data binding is awesome and neat and shiny and chrome. It's also pretty slow; a lot of pragmatic angular work involves keeping the number of watchers firing during digest cycles minimized. If you have a lot of data that's all two-way-bound by default, but aren't making any use of the bindings, that's a lot of wasted cycles. I mean, my app has a lot of data in it, stuff like {{username}} which rarely ever changes in the model, so I don't really need two-way binding for it.
What I like here is that one-way binding is the default, and you can do two-way stuff if needs be, because sometimes it really is the best call.
I think two-way binding going by the way side because developers are tired of having to deal with unintended loop backs. You start having to add weird flags to your data to indicate that data changes were the result of user actions and not changes from the backend to avoid endless event loops. Two-way binding results in more code that's buggier whereas one-way binding with actions results in much more organized and understandable code with none of the unintended consequences.
I'm thinking that's a framework-specific or coding-style issue? From using a number of frameworks, I've virtually never had issues with endless loops. Perhaps it helps that frameworks like Knockout, etc don't trigger change events when the value is the same.
This seems to be the new standard in JS framework development. Ember, Angular and React have all switched to making "data down, actions up" be their M.O., while still supporting 2-way data binding if you want or need it.
Thanks. Yeah 1-way as default is reasonable. I suppose in my case I haven't seen performance issues due to data size, and also have taken to using RactiveJS which allows both 1-way and 2-way via [[someProp]] and {{someProp}}, respectively.
What I like here is that one-way binding is the default, and you can do two-way stuff if needs be, because sometimes it really is the best call.