Except this time better because it’s written by a junior developer pretending that he knows what he’s talking about!
Better still, I’ll ward off all the readers who only entertain articles with code — this has words, and only words… actually it also has dank memes and poorly-placed pop-culture references. Before we begin, a few prefaces:
I’m going to refer to React as a framework to save some characters — whoops there goes my last reader! I know it’s a library, but I’m assuming you’re using many other libraries in conjunction with React itself.
I’ll keep this blog up-to-date on a bi-yearly basis.
(edit: October 2022) That's a lie ^
“Should I learn React or Vue?!”
I’m sure we’ve all seen this question asked — maybe it was versus INSERT_FRAMEWORK_HERE instead. Honestly, it’s a fair question — especially for new coders! Web developers are being stretched in a dozen directions simultaneously, and they’d like to finally be told, “Just learn React because you can get a job with it…”
“Look, Smithers! I’ve already upset all the Angular developers!”
- Devs gotta eat.
- Devs eat by getting jobs.
- And front-end devs get jobs by knowing how to utilize front-end frameworks successfully.
Capisce? Capisce. Now for the actual comparison.
I like both React.js and Vue.js, and I don’t know if I can definitely say that I prefer one to another. *GASP*
Despite “completing” a large-scale project with each framework, and working on many smaller-scale items with React, it’s only really clear that there are advantages and disadvantages with each framework, but not a clear winner. *GROAN* “You’re supposed to choose one!”
No, I won’t choose one ultimate winner, but I’ll give you many solid distinctions with which you can easily make your decision. I’ll start with a meaty topic first, but any new devs reading this shouldn’t get scared off! Just skim the talking points to find one that you care about.
One-way data binding alone makes React a much better tool for providing extendible code that many developers can easily work on. In my opinion, the two-way data binding that Vue offers (and Angular forces) is a poor solution to simple state management. Angular and Vue developers have told me that they do not enjoy having to do so much boilerplate in React (recreating form input components for example), so they look forward to two-way data binding and in-HTML syntax as a way to avoid reinventing the wheel with forms. This is helpful for small-scale applications, but when crafting larger products that contain omnidirectional local and global state, you’ll need to integrate Vuex — Vue’s state management system. The problem now is that all
v-bind instances that play with store managed state will now have difficult-to-track state. You may say: “Well, if you know there will be a lot of state management, simply don’t use two-way data binding in Vue — it’s optional!” To that I say: find me some examples. I found this well-written article (it’s well-written because the author agrees with me) on attempting to adhere to one-way data binding in Vue, but it’s not pretty. Two-way data binding is encouraged in every Vue tutorial I’ve ever seen, and I believe this teaches new front-end framework users bad habits with state management. At the very least, optional two-way data binding leaves new front-end framework users without clear lines on when and how to use the “optional” (yet profusely encouraged) feature.
Forcing one-way data binding in React makes shooting yourself in the foot with state more difficult. This whole paragraph can easily be summed with: I like immutability, so I like React over Vue in terms of state management. It seems like React users are forced into becoming damned sure that they understand state early in their learning. Meanwhile, Vue developers do their best to avoid Vuex and are led down the path of unmaintainable state. Being forced to learn about state early on means that React enjoys a steep learning curve, but it’s for the best. Sure, you could technically use Vue and force one-way data binding, but its documentation encourages the usage, and attempting to do would absolutely require the understanding of Vuex (which I believe is more difficult to utilize than Redux purely due to a lack of large-scale examples to analyze). It’s possible to utilize two-way data binding in React, but documentation, the community, and all of the tutorials you will find online heavily discourage it. There are even many helpful articles defining when you’re going to want to bring in Redux (React’s state management system). I’m gonna hope that you read that instead of looking for the bold text exclaiming a winner, but — in regards to data binding — I believe React wins by forcing one-way data binding upon you. In my experience, it reads better and it tests better.
Ease Of Initial Use:
This is a weird metric to calculate, but I can hand-wave my way through an explanation…
These aren’t the droids you’re looking for…
Let’s say that a new front-end framework user is happiest with:
- A bigger community
- A high runway take-off speed (speed at which you can make full use of the framework)
- The ability to easily and quickly create a static web page with dynamically-rendered components.
There is no doubt that React’s community is the strongest between Vue and React, hell — it may be the strongest library community PERIOD. I can’t go through a week without seeing an experienced developer write an amazing article on how to utilize React in some fresh new way. Vue has a super active Discord server, but new learners are often pointed to examples that use outdated or unofficial libraries — at some point when writing Vue, you’ll be forging new territory. React has the better community for now.
As for getting off the cinder blocks, both frameworks have an official solution. React has
[create-react-app](https://github.com/facebookincubator/create-react-app) (CRA) and Vue has
[vue-cli](https://github.com/vuejs/vue-cli). CRA is cool and powerful, but I’ve met multiple developers who are literally scared to eject, and why wouldn’t they be!? Facebook scares the shit out of you for even suggesting it as an option. Without encouraging you to eject, you may not get to experience the magic of maintainable stylesheets! I also imagine a day in the future when Vue’s community is even remotely close to React’s in size. There would likely exist an amazing number of relevant vue-cli templates! It sounds like a beautiful future, and it’s easy to get up to a similar build configuration, so Vue is easier to get right into it.
What’s easier to make a simple web page with? In my experience, hands-down the answer is Vue. I feel biased having already learned React before learning Vue, but I’ve never found a cheaper, better, or more comprehensive learning resource than Maximilian Schwarzmüller’s Vue.js 2 — The Complete Guide. In the end, this metric comes down to personal preference, my omniscient experience using both frameworks, and my all-powerful ability to unilaterally decide wether Vue or React is easier to learn initially. The ability to use the Vue API as a quasi-jQuery way to manipulate the DOM allows for a slow slope into the world of front-end development. While I don’t like declarative DOM binding in practice, it’s easy as hell to render a list of items with
v-for in Vue than mapping a `const` in React. It’s way easier to blast through a static page with Vue.
In conclusion — and by a thin margin — I have declared that Vue is easier for first-time front-end framework users. As already previously discussed, I do think this comes at a cost.
Styled-Components, CSS Modules, Radium, Glamorous, Stylus-Loader, ReactCSS, Nano Component, CSS-in-JS, Styled System — that’s just a few of the different libraries you can bring in to deal with styles in React. This is heinous. The fact that before you even create a product you’re supposed to somehow know whether or not you’ll want to render a prop-based style or dynamically pass styles with only non-store state changes rattles me. If you decide to jump head-first into ______ you may encounter pitfalls with the implementation later on — hell you just may not end up how it looks in your code, but none of them are very interchangeable. Unless you have a Webpack wizard in your team to set you up with a slam-dunk solution, React does a piss-poor job of handling styles.
This image is so positive — as if it’s a good thing to try and decide between all this bullshit…
Meanwhile, Vue nailed the “single-file web development” idea. JSX is a nifty concept, but the problems with stylesheets and a lack of opinionated development makes a well-defined Vue project look like water in a desert. CSS, Sass, Stylus, Less? No problem! Just drop in vue-loader. Worried about global styles getting in the way? Just add
scoped to a Vue component’s
<style> block and attach unique IDs to every class. Worred about dynamic stylings in Vue? Here’s a 2-minute read detailing all the good ways to handle it. Vue ❤ Styles.
Plays Well With Others:
I love Vue — I really do, but all my initial fanboyism the framework goes out the window if you tell me to make sure the code needs to play well with other devs. There is ass-loads of research to be done into properly utilizing Vuex, making sure that your code is extendible and readable. The smaller Vue community exacerbates this problem. React has been around longer and has a huge number of developers maintaining years of best practices. Vue’s template syntax (the modifiers, attributes, directives, and other “in-template” actions) make spooling up dynamic applications a breeze… It also makes it easy to run away with difficult-to-test code that can quickly look like soup to your coworkers. I simply don’t like in-HTML functionality. I believe that dealing with the mixed template and script functionality in Vue adds a lot of vertical eye movement and makes it difficult for me to traverse a mental stack. Weird situations also existed with the templating syntax iN Vue. For example, you can only use
kebab-case for custom HTML attributes. It’s not a big deal, but it is very annoying to CTRL+F the corresponding
TitleCase name of binded properties.
One-directional data-flow in React means that I only need to watch out for props within the template. Also, any kind of conditional or data-driven rendering in React is always at the top of the
render() function. It’s easy to bounce around JSX. I may feel this way because I came from the perspective of learning React first or from not using Vue enough, but — currently — I think React is much better to use in a team environment.
Please see edits at the bottom of the page after reading the recap.
- If you know about state, and you know you’ve got a big project planned with intertwined local/global state, use React.
- If you’ve never used a front-end framework before, and are just trying to have fun on your own, use Vue.
- If you’re a designer that cares about maintainable styles, use Vue.
- If you’ve got a team and you’re looking to choose between the two for a project, I suggest picking React.
- As a small aside, if your project demands serving up a very slow internet connection or older browsers, but you don’t want to deal with the relatively empty communities of Preact and Moon, I would choose Vue because it has a faster virtual DOM and a smaller footprint. The differences in speed and size really only matter if you need to serve 3rd-world customers.
In reality, you should try to learn both if given the opportunity. I’ve learned so much from each framework’s community and documentation. Special shoutout to Max on Udemy for a truly complete course on Vue, and thanks to Wes Bos for providing the best React education on the web. I look forward to any feedback in the comments.
This is modern web development and the world moves fast!
one-loader for React that mimics
style-loader working in conjunction to create
.one files with
<style> tags! Check it out here. I haven’t gotten to use it in any projects, but the odds are it makes my argument for Vue in that case pretty untenable — which is fair since that was the result of Vue treating Webpack as a first-class citizen and not the Vue framework itself being somehow intrinsically better with styles than React.
Additionally, Dustin Schau made this CSS-in-JS Playground allowing people to easily see the differences between every library. After using
styled-jsx, I’m still adamant that it’s not the solution, but Emotion is my favorite of the ones I’ve used.
Vue will catch up in v2.6, but React has error boundaries now, and that stuff is awesome.