Hacker News new | ask | show | jobs
by liscovich 4245 days ago
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?

4 comments

Meteor doesn't use two-way data binding. You have template instances, which are wrapped domranges based on handlebars templates that call helper functions (one way binding). You then have event handlers for templates that you assign to class selectors, which will be delegated to each template instance that is created. You then manually change the data within event handlers.
I don't believe Meteor has two-way data binding. You have to update the model manually using events[0].

0: https://docs.meteor.com/#/full/eventmaps

Two way data-bindings are not a Core feature and they are implemented in packages. My favorite one is this: http://viewmodel.meteor.com/
That's an interesting point. I find two-way binding to be very convenient, but I wonder if the industry is moving towards a one-way bind solution (at least it seems like a common theme with most front-end frameworks).
You are not.
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?