This is quite surprising to me. I know that Pete Hunt -- one of the authors of ReactJS -- and one of the main proponents of using it in conjunction with Flux, gave a talk at Meteor Devshop 11 earlier this year (http://youtu.be/Lqcs6hPOcFw?t=48m7s), and didn't say a word about the problems associated with two-way data binding. To me that would seem to be the elephant in the room. Is that because he treats Meteor as a framework for prototyping and smaller scale apps?
I wonder if the criticism that the Flux team at Facebook has directed at two-way data binding is also applicable to Meteor. Jing Chen is her intro of Flux (https://www.youtube.com/watch?v=nYkdrAPrdcw&list=PLb0IAmt7-G...) says that two-way data binding creates a major challenge for scaling applications because views can trigger changes in data, and data changes can trigger cascading changes in views, which makes it very difficult to predict the behavior of the app as a whole. Wouldn't Meteor face the same challenges?
In other words, if you believe that the Flux design pattern (which involves a central dispatcher as the only entity capable of updating the data) is sound, shouldn't you stay away from Meteor's model when building large applications? Or am I missing something?
https://www.wsj.com/articles/twelve-days-in-xinjiang-how-chi...
If you don't have WSJ subscription, paste the title into FB's search bar, and open the link via search results to bypass the paywall.