They are just different, and that's where a lot of the arguments come from.
For me, Vue is such a monumentally large step backwards. I loved React because there are no templates, there is no 2-way binding, you don't have the vuex style state handling. Using Vue is an exercise in frustration for me, dealing with all of the templating headaches that I was so happy to escape, needing to learn the "template pseudo language" which ties your hands in a way that I haven't found helpful. But this makes Vue no more wrong or worse than someone using tabs instead of spaces is "wrong" or "worse".
But for others, React is a nightmare because of those reasons. A friend of mine greatly dislikes the React paradigm, and was always more productive and wrote better code in a templating style. And I genuinely don't think it has anything to do with productivity or skill. Vue's style might be better at some things, worse at others, React is the same, but in different ways. They are both fantastic frameworks.
There is a huge deficit of intermediate-advanced Vue tutorials compared to React. There are like 30 advanced-level tutorials on Egghead on React and like, what 3-4 advanced Vue tutorials (Nuxt, Nuxt and using Angular-like decorators to write proper classes instead of the 'it just works' vanilla boilerplate)?
Learning the ropes of Vue is easy. It's a go-to framework of the Laravel crowd for this very reason - you don't need to know Javascript much if at all, just learn some basic syntax and you're good to go for some basic virtual DOM magic.
Also, Vuex is very string-based, so you don't get payload or return type checking when you use Vuex. There are additional libraries that look to help this, but it's still an issue.
I could be wrong about any of this, but those are currently the issues I'm running in to.
- JSX fixed all the templating issues from 10 years ago, i see no reason to go back to dependency injection, scope loss, arbitrary code-in-html expression and a semi-javascript accent
- Presentational view logic belongs to the controller while business logic is elegantly abstracted in React: view=fn(state). There's no point in ripping view creation from the presentational layer.
- Context and higher order components. Can't have those in an imperative architecture.
- v-for is not sane to me. Also odd, being forced to mix-in extensions for the simplest basics that go beyond the few presets Vue provieds: https://github.com/Krizzu/vue-for-range A React user doesn't solve problems by searching the internet for framework specific solutions, they import _ from 'lodash' and use _.range, like everyone else does.
- {condition && <div>hello javascript</div>}
- We have suffered through two-way data bindings with Angular already
- Vuex is not native. It mutates state by aggressively transforming state into setter/getters, with nasty edge-cases. Once Vue switches to version 3 using proxies, you'll maintain two incompatible codebases. React has Mobx, even though Redux is great. Also lots of lean and promising alternatives like Unistore.
- Knowing React you don't rely on documentation (though official docs are on point). It is simple enough to grasp it after looking at a view examples once. The api surface and cognitive overhead of React is a tiny fraction of Vues. Coming from Angular it is amazing that one month of learning and half a year of consulting docs turned into a week and a couple of months consulting with Vue. Yet, you can learn React fully in the shortest amount of time while simply remembering the few things you'd need to know. A generic round-trip, for instance the one at egghead, costs you 60 minutes total.
- http://www.npmtrends.com/angular-vs-react-vs-vue-vs-@angular...
Windows: https://github.com/Microsoft/react-native-windows
Macos: https://github.com/ptmt/react-native-macos
Linux (Qt): https://github.com/status-im/react-native-desktop
AR: https://github.com/HippoAR/react-native-arkit
VR: https://facebook.github.io/react-vr/
TV: https://github.com/react-tv/react-tv
Shell consoles: https://github.com/Yomguithereal/react-blessed
Word: https://github.com/nitin42/redocx
Pdf: https://github.com/diegomura/react-pdf
3d: https://github.com/Izzimach/react-three
Sketchapp: http://airbnb.io/react-sketchapp/
Keynote: https://twitter.com/nishb1/status/913744410537537536
Hardware: https://github.com/iamdustan/react-hardware
Samplers: https://twitter.com/GabeRicard/status/911989894267973633
And so on ...
Finally being able to transfer knowledge and code, and due to the generic nature of React in some cases even everyday eco-system packages can be applied. For instance: https://github.com/gaearon/react-blessed-hot-motion (native console app using plain react-motion to move stuff around).
- Don't need to know jsx!
But you need to learn Vue's template DSL. JSX is just HTML and JavaScript.
- v-for looping is saner than reacts mapping
- v-if allows v-if statements without renderIf component or multiple render statements in react (antipatterns boo!).
Strongly disagree!
- two way data binding with vue-model
I suggest anyone thinking of using two-way binding for anything to rethink their choice. There is always a better way.
In case you don't know (and I also didn't until recently), those namings come from the HTML DOM Javascript API, and not from React. So having that naming in React+JSX is more a consequence of operating on that abstraction level, than a quirky decision of the React developers.
for and class are reserved statements, hence htmlFor and className are the official api names, in other words they belong to the actual web-api spec, there's nothing arbitrary about it:
https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelEl...
If you really dislike it, you can still use class and for: https://github.com/insin/babel-plugin-react-html-attrs
> or I would be able to write a simple if-else statement
{} evaluates to a ternary. You can use if, according to the spec that's what do expressions are there for.
do {
if (condition) <div>yes</div>
else <h>nope</h>
}
condition
? <div>yes</div>
: <h>nope</h>
These two things are explained in a single sentence, every tutorial eases you into it, the first thing that comes up once JSX is mentioned.
const { for, class } = this.props
const { for: forHtml, class: className } = this.props
v-model isn't two-way binding in the AngularJS sense; it's just a shortcut for binding a "value" property and updating it on "change" events. See https://vuejs.org/v2/guide/forms.html.
Gitlab sums it up for me "Vue isn't a buzzword, Vue is a workhorse" https://twitter.com/gitlab/status/928675879676497920
Each component I have in React is script + css. It did require some setup though.
> - Don't need to know jsx!
Except you need to learn the v- bindings. I prefer JSX and JS here.
> - two way data binding with vue-model
Two way data binding is a problem, not a feature.
Vue's "two way databinding", i.e. v-model directive, is actually just a syntax sugar that's equivalent to adding an event handler and a dynamic property on the value/text of the element.
Maybe it's better in Vue than it was in AngularJS, but this seems like a downside to me.
You don't need to know jsx for using jsx. You only need to know html. You do need to learn something more with vue, you said so yourself, those v-for, v-if directives.
> each component is html.file, javascript.file, css.file
I prefer to only have one file per component so that I can just "import Component" and use it. With 3 files I need to make sure all 3 of them get loaded. Disclaimer: I do not know how Vue works.
The rest sound interesting.
That means that there is a "blessed" solution for styling, that I'm afraid React will never have. Between "styled components", CSS-Modules, css-in-js, and tons of other options, many in-operable with each other. Styling is React's worse part, and it doesn't look like it's getting any better...
On the one hand this offers a lot of flexibility to do things the way you want, but also makes the learning curve a lot steeper. Honestly I would love for somebody to build a more full fledged framework around React that makes most of the decisions for you. A sort of "good for 90% of use cases" setup. (I guess create-react-app is sort of like that? You still have to make too many decisions, I think.)
Most of the other parts of React are great with the freedom of choice. I can use a 3rd party component that handles it's state internally, or expects to be controlled externally, or uses or doesn't use JSX, or organizes it's code however it wants. But if I want to style it (which i'll need to do), I need them to support the method I'm using in my app, or have this very ugly and hard to support "bridge" between what I'm using and what they are using.
I'm not trying to be all doom-and-gloom, but it is a pain point for me, and it's not getting better in my experience, it's getting worse. It's not nearly bad enough to get me to switch away from React, but it's something I would like a nicer solution to.
Because in the end, Vue.js has stuff in common with React, like the virtual DOM (you don't see this in Angular 2+) and has stuff in common with AngularJS (the good parts).
Check this out: https://vuejs.org/v2/guide/comparison.html
Don't go thinking you are going to read a biased comparison, the Vue.js vs React section has the blessing from a core React contributor (Dan Abramov): https://github.com/vuejs/vuejs.org/issues/364#issuecomment-2...
- Don't need to know jsx!
- Sane way of scripting puts the script in an object and each component is <template>html</template> <script>javascript</script> <style>css</style>
- Event buses allow sharing of variables between child components without either redux or pushing variables down one child at a time (finally!)
- v-for looping is saner than reacts mapping
- v-if allows v-if statements without renderIf component or multiple render statements in react (antipatterns boo!).
- two way data binding with vue-model
- native vuex with an index file that holds state sanely, rather than just having state held in each reducer as done in react
- Great documentation!
- Yay !