5 ms·
I was very interested in Vue.js initially, but I had to pass once I realized it uses two-way data-binding. I prefer React.js since it has less behind the scene
by wintorez 9y ago
I was very interested in Vue.js initially, but I had to pass once I realized it uses two-way data-binding. I prefer React.js since it has less behind the scene magic than Vue.js or Angular. Although I like certain aspects of Vue.js which I think React could learn from.
- badthingfactory 9y agoI'm not sure I understand rejecting a library because it allows two-way binding. If two-way binding doesn't work for some control, nothing is stopping you from falling back to one-way binding.
- Klathmon 9y agoThere's something to be said about staying as close to the "intended" way of doing things as possible with libraries. Yeah, you might be able to stick with one way binding, but anything that interacts with vue will most likely expect 2 way binding, as well as most learning resources. Updates and improvements will be made with 2 way binding in mind, and you won't have nearly as many "coded with vue in mind" tools or libraries to use. It's possible, and it might actually work out just fine. But in my experience going "against the grain" with libraries only leads to pain.
- outsidetheparty 9y agoI really haven't found this to be the case. One-way data binding is the default for just about everything in Vue; the only exception is v-model which is generally used only for form fields or similar elements where two-way binding makes sense -- two-way binding is definitely not pervasive throughout the framework as in Angular. Apps of any complexity tend to use vuex (which is a sort-of-flux-like data store) for state management.
- Klathmon 9y agoWell then it seems I'm horribly wrong here! I haven't really used Vue (only angular) and I made a bad assumption, but my point still stands in a more general form.
- outsidetheparty 9y agoOh, I totally agree with you -- I'm an Angular refugee myself. I'm genuinely surprised by how many people in this discussion seem to have such wildly incorrect impressions of what Vue is like.
- debaserab2 9y agoFor the same reason you don't buy a truck if you don't intend to haul things. You use a library that suits your workflow best.
- badthingfactory 9y agoI would say it's more like purchasing a standard transmission instead of a semi-automatic transmission because a standard transmission gives you better control on slippery roads.
- hajile 9y agoEver bad language feature gets used eventually. This is doubly true for frameworks where not only are bad features used, but also unintended and hidden features. Even if I know when to avoid 2-way binding, there is a high likelihood that someone else does not or does know, but adds a TODO because they "didn't have the time" to do it right. In my view, the best solution is to (as far as possible) eliminate questionable features from the framework and enforce good practices.
- madeofpixels 9y agoI'm new to these kind of frameworks. I have been hacking away some small apps. Do you mind explaining why two-way data-binding is a "bad" thing?
- Klathmon 9y agoI'm not the guy you asked, but for me it's not that 2 way binding is bad, it's that one way binding is better. Using one-way binding you get a very clear picture of how data flows through the components. Components pass data to their children via props, and get data back from the children via callbacks. It forces you to be more explicit with how things are working. With 2 way binding, you don't have any guarantees that the child won't be modifying what you pass in, and in many cases i've found that it's difficult to see which direction data is flowing just by looking at the component. If your component had a property named "value", is it the component filling that in and passing it to the parent? is it the parent passing the value to the child? With 1-way binding you know value is being passed "down" to the child, and a property named something like "onChange" will be the callback that it uses to pass data back "up".
- wintorez 9y agoI couldn't agree more with the above. I firmly believe that "Explicit is Better than Implicit".
- madeofpixels 9y agoThanks for the reply. I think I can understand why two-way data-binding would be bad on a complex app. Or even with more than one person working on the app.
- Klathmon 9y agoNo problem! And again I do want to stress that two-way binding isn't necessarily bad in my opinion, it just doesn't "require" the explicitness that one way binding does. I have seen 2-way binding work wonderfully when used with some strict guidelines or with external tools that can enforce some of that explicitness. And it can have it's benefits! 2-way data binding is often simpler, and can be faster than one way binding (it's really just a fancy term for "pass by reference").
- ry_ry 9y agoVue is really interesting, but feels like it's retreading some of the missteps of frameworks past. I worked with knockout extensively on an inherited codebase a few years ago and my overriding opinion was that 2 way binding sacrifices everything for convenience.
- kylestlb 9y agoEverything? Here is what the recommended use of two-way binding does in VueJS: "You can use the v-model directive to create two-way data bindings on form input and textarea elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases." Seems like a very specific, deliberate functionality. Changing a value of a reference from a parent component, however, is advised against and is probably what you're referring to.
- cjalmeida 9y agoIMO, that's the beauty of Vue data binding. It will work as you'd expect for the majority of cases (ie. simple form binding) without the boilerplate and shooting you in the foot.
- mmanfrin 9y agoYou don't need to use two-way binding. You get one-way by just making things props.
- jgalvez 9y agoOne thing I'll mention is that even though Vue.js has more "magic" than React, its implementation is substantially smaller in size than React. I guess its centralized nature (one major developer) plays a role in this. React is backed by the Facebook engineering team, which is both good and bad -- a group is a bug with a brain on each leg. I think for this reason it's burdened with a noticeable measure of over-engineering.
- abritinthebay 9y agoIt's mostly because React does more behind the scenes. You can argue if it should do more but it is doing a lot more stuff than Vue, it's not simply bloat. Questioning the utility of that stuff is quite reasonable however.
- linkmotif 9y agoBest thing about React is that I know absolutely nothing about its implementation.
- jankiel 9y agoTwo-way data binding is only syntactic sugar for setting value as a property and assigning it's value on event listener. You can read about it in the docs
- nightski 9y agoExcept it has a drastic effect on the architecture and data flow of your application (which some believe to be detrimental). I think this is more what the OP was alluding to.
- balfirevic 9y agoNo, in Vue.js it really doesn't have any drastic effect - or almost any effect on what you would call "architecture". I have to ask - are you just talking abstractly about two way data binding or specifically as implemented in Vue.js?
- nightski 9y agoI was speaking more generally but yes, even in Vue.js it does. It's impossible to escape for any data-binding system. The reason is that "effects", "data modifications", or whatever you want to call them are now local and appear everywhere. As your application grows it becomes harder and harder to know where and how your data model is updated. This becomes especially apparent as you introduce more complicated workflows where you can't update a single value of state at a time but instead would like to treat it as a transaction. It can also appear when dealing with computed/derived state. Two-way data binding is fine for a simple form of 5 values. But once you start trying to build a larger application the desire for a top-down data flow and isolated state modifications becomes very apparent. It's not an attack on Vue.js, as you have options like veux. I'm merely stating that there are very large disadvantages to two-way databinding itself.
- balfirevic 9y agoI'm having a hard time reconciling what you're describing with the Vue.js development experience. I have lot of experience with Angula so I understand what you're saying. But in Vue, two way data binding is _very_ local. It doesn't appear everywhere, on the contrary. It's barely worth mentioning when describing how development works. Honestly, this whole debate just seems weird - take away two-way data binding from Vue.js and at most you'd get several sighs from developers as they change few form-handling lines of code.
- dabernathy89 9y agoThe current version of Vue does not favor two-way binding (although it is still technically supported using `v-model`, it's entirely optional).
- manigandham 9y agoThere always seems to be misunderstanding about this - Vue only does "2 way binding" for local state within the component, and is purely syntactic sugar around you coding a setter/getter yourself. That's all it is. Any cross-component communication is done with events/mutations/actions, ideally with a central state store. This offers the perfect mix of readable, understandable, composable, testable state architecture without the constant verbosity of binding everything yourself.
- Can_Not 9y agoIn vuejs, two-way data binding is an optional feature, it's not a default and it's usage is not encouraged for beginners who aren't sure if they should use it.