However, I do have a BIG problem: the fact that mutating the data automatically does a rerender is a nice idea, but in practice it falls apart very quickly and leads to fairly hard-to-debug bugs. For instance, if I add a new field to an object, it will not be detected as a change by Vue and not cause a rerender[0]. In my case, it broke the magic and caused me to look into how the heck did vue actually work - only to find out I had to call this.$forceUpdate() in a few places. It's terrible.
React, despite its problems, is nice because of exactly this : its data binding is entirely non-magical. You have to go through setState or force an update. The mental model is dead simple. I wish I could like vue more...
I feel you could have avoided this "awful" pain by just reading a little documentation.
I mean, how exactly did you think your new property would be picked up? I know frameworks are supposed to abstract over things but you do still need some idea what's happening under the hood.
Vue.set is the way to go here, which used to be more prominent in the docs. The section that called this out (along with other reactivity "gotchas") has apparently been removed from the latest version.
The problem is, Vue.set is documented exactly nowhere in the getting started guide[0]. In my case, I couldn't use it because I wasn't the one modifying the data binder, d3-force was. But either way, this should definitely be in the guide !
Besides, it's possible for the new property to be picked up through Proxy Objects[1]. So it's not like it's entirely impossible for Vue to do this, they just chose not to (and they probably have good reason, like IE support).
I spend a good amount a time answering questions in the Vue StackOverflow tags. While this is documented, it's nevertheless something a huge amount of people stumble over. I'd say the change detection caveats are right behind "this" issues (which isn't really a Vue issue, just javascript) in terms of the most common problems I see in Vue code.
Thanks for the hint. This will help me in my own project.
One question: Which objects will Vue attach observers to? Just props and data? I sometimes reference objects in Computed values, but those objects never seem to force re-rendering when they're changed.
Vue is relatively simple and the Vue docs themselves are comprehensive and excellent.
There is a culture of complexity and some people thrive and perpetuate this complexity for not always technical reasons.
Vue completely avoids and sidesteps this and its best to start with the original site and docs or you might find yourself sucked once more into this gratuitous complexity.
I've been using Vue for about a year now. It's been my lib of choice for rapid front end development. Quasar Framework with it is especially a productive combination.
In comparison to react, it's always been more intuitive.
That said, I recently started working with a developer new to vue coming from react. Explaining how nested data updates doesn't really work made me realize how janky it is.
I hope there's some kind of solution. Especially when you start using vuex, the data update inconsistency becomes a major issue.
Vue doesn't force components or build tools on you. You can drop it as a 30ko script in an html tag and put the template in the html file for small projects, then go full webpack + components as it grows.
Managing state is very natural on small projects, but you can use the official, well integrated store.
The doc is stellar. The api is simple, with no surprises, and riddle with small helpers to make your life easier. As a result, reading the official tutorial feels like a friend is talking to you.
Debugging and training are easy.
I do mostly react for my clients, but when i can choose, i always go for vue.
And compare it with the Options / Lifecycle Hooks and Instance Properties and Instance Methods sections of the Vue API docs:
https://vuejs.org/v2/api/
Vue may be simpler if you have passing familiarity with Angular 1, or if you are very familiar with Mustache-style templates. But I think it's wrong to say the API is simple, or has a small surface.
The naming all life cycle methods, the grouping of things by categories in data, methods, all the things you don't need to learn to make jsx do what you want, the whole props/callback things that is vastly simpler, no set state shenanigan, no two ways with consequences of creating components, the use of standard html attribute names and not js dom api names, etc.
That makes manipulating the api way simpler for me.
There are surprises. Reactivity with child components, and how to deal with that - there's enough "this isn't what I was expecting" that I run in to a lot in the forums that it's certainly a "surprise" to many.
Simpler. Have standard router, Vuex store, so no need to choose which router to use, Redux or Mobx etc. Compatible with web components. Standard way of creating plugins/middleware and project templates. VueJS is more of a framework than React's view component. No 'concern' over the licensing. Use JSX or not is up to you. Smaller size. My bet is VueJS is likely to be the next JQuery. I switch from React and life is better.
But how is the JSX story in Vue? Every time I ask this I kind of get crickets, because it seems just about everyone is using the default template syntax.
Two-way databinding is not supported by Vue 2 if I remember correctly. You can do it, but you'll get console logs, about how you should avoid doing it.
Two-way binding does exist, just not in the same problematic way it existed in Vue 1. It was changed to just be syntactic sugar for the event handler approach - https://vuejs.org/v2/guide/forms.html .
A small factor but a big one imo is that vue-cli is an infinitely tidier affair than create-react-app. It's very easy to get through your first few apps and tutorials with Vue because they're usually following the exact same base.
Vue DevTools (with Vuex support) is a much more pleasant experience than React/Redux Dev Tools as far as Chrome integration goes too.
I would suggest to visitors to Vue to not dive into using something like Vuex unless you really know need it - IMO it's not at all a 'by default' library to bring into a Vue project.
Give a try using only props and events. You will save a lot of typing and brainpower avoiding actions, mutations etc. I work on a fairly large, at this point, Vue application, and I am pleasantly surprised how far we've gotten without global state stores.
Agreed. I looked at Vuex and it seemed unnecessarily complex for most projects. We just have plain state objects that get passed to components that need them, and a convention that components call methods on the state rather than modify its properties directly.
There's an "awesome-react" list [0]. Also, I personally maintain a large list of links to tutorials, articles, and resources for React and Redux [1], as well as a list of Redux-related addons [2].
1. The API surface is fairly small, especially compared to Angular. I could grok how it worked very fast.
2. The fact that it works without build tools is a godsend. My project is fairly small, and having as fast an iteration cycle is really nice.
3. The debug tools are awesome. EDIT: https://github.com/vuejs/vue-devtools
However, I do have a BIG problem: the fact that mutating the data automatically does a rerender is a nice idea, but in practice it falls apart very quickly and leads to fairly hard-to-debug bugs. For instance, if I add a new field to an object, it will not be detected as a change by Vue and not cause a rerender[0]. In my case, it broke the magic and caused me to look into how the heck did vue actually work - only to find out I had to call this.$forceUpdate() in a few places. It's terrible.
React, despite its problems, is nice because of exactly this : its data binding is entirely non-magical. You have to go through setState or force an update. The mental model is dead simple. I wish I could like vue more...
[0] It is somewhat documented here: https://vuejs.org/v2/guide/instance.html#Data-and-Methods among other places