One 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.

It'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.

Best thing about React is that I know absolutely nothing about its implementation.

Vue 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.

Everything? 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.

IMO, 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.

Two-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

Except 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.

No, 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?

I 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.

I'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.

You mistake 2way data binding with ui decomposition and right view model structure, if you have those problems. With the right view models everything becomes is easy and simple, but you do not get there right away, it's hard to learn, and no framework will bring you there. This is due to ppl spending way to much time chasing frameworks in vogue, than learn to architect applications. I love vue btw.

I'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?

I'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".

FYI, Two-way binding in VueJS isn't about parent-child communication. It's about binding to input fields and other interactive HTML elements:

"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."

So... I think the term "two-way binding" is overloaded here, and paints an improper picture of what VueJS is actually about.

Thanks 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.

No 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").

I couldn't agree more with the above. I firmly believe that "Explicit is Better than Implicit".

In general, it's harder to reason about as to which way the data is flowing.

There 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.

You don't need to use two-way binding. You get one-way by just making things props.

I'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.

Ever 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.

There'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.

I 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.

Well 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.

Oh, 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.

For 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.

I 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.

The current version of Vue does not favor two-way binding (although it is still technically supported using `v-model`, it's entirely optional).

In 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.