Yet Another React vs. Vue Article

Data Binding:

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-model and 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…

Let’s say that a new front-end framework user is happiest with:

1. A bigger community
2. A high runway take-off speed (speed at which you can make full use of the framework)
3. 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 (CRA) and Vue has 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.

Maintainable Stylings:

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.

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 camelCase or 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.