Vue vs React: Battle of the Javascript Frameworks

React or Vue.js, which JavaScript framework should you choose? React powers WordPress’ new editor while Vue.js is a popular framework in the Laravel community.

In this post we’ll go over what these two popular frameworks are all about, some use cases and see how they’re similar and how they differ.

The Contenders

I would guess that many front-end web developers have heard of the open-source JavaScript UI framework developed at Facebook called React. It powers most of the Facebook website as well as Instagram. It’s also the JS framework used by Gutenberg – WordPress’ new editor.

React was a bit of change in the JavaScript world when it came out as it’s quite different from other at-the-time frameworks like jQuery, Backbone.js and Angular 1. The biggest difference is that React popularized a Virtual DOM (we’ll get into this later) and created a new syntax called JSX that allows developers to write HTML in JavaScript. WAT?

Vue.js is a similar web development tool – it’s a JavaScript framework that aims to tackle the same problems as React but in a different way. Vue.js uses a template system instead of JSX, arguably making it easier to integrate into existing web applications. Because the templates use regular HTML Vue.js can be integrated into existing code quite easily, without the need for a build step. Vue.js is also said to have a flatter learning curve as well – something that I’ve recently verified as I’m new to Vue.js. The other main thing to mention about Vue.js is that it’s development is not backed by a large corporation like Facebook.

Similarities

React and Vue.js have a lot in common as they’re both UI JavaScript frameworks focused solely on creating rich front-end experiences. Unlike earlier JavaScript frameworks that had ‘batteries included,’ both React and Vue.js are fairly barebones with functionality like routing and state management handled by separate frameworks.

Usage of a Virtual DOM

One of the biggest similarities between Vue.js and React is the usage of what’s called a ‘Virtual DOM’. A Virtual DOM is basically what it sounds like, a virtual representation of the DOM tree. It hinges on the concept that updating the real DOM frequently is computationally heavy. Updating JavaScript objects is relatively lightweight by comparison.

With a Virtual DOM, a JavaScript object representing the real DOM tree is created. Updates to any element are made in the Virtual DOM rather than the real DOM. When something is changed, a new Virtual DOM object is created and the changes between the old and new are determined. These changes are then applied to the real DOM.

For example let’s take this list in HTML:

<ul class="list">
  <li>item 1</li>
  <li>item 2</li>
</ul>

In JavaScript this could be represented simply as:

{
    type: 'ul', 
    props: {'class': 'list'}, 
    children: [
        { type: 'li', props: {}, children: ['item 1'] },
        { type: 'li', props: {}, children: ['item 2'] }
    ]
}

Actual Virtual DOM implementations are more complex than this, but they’re essentially a nested JavaScript object with nested arrays.

When a new item is added to this JavaScript object a function will ‘diff’ the changes and apply the new markup to the real DOM. This ‘diffing’ algorithm is the secret sauce, and both React and Vue.js do this a bit differently.

Vue.js is reported to be able to diff changes to the Virtual DOM more quickly as it keeps track of each component’s dependencies during render, not needing to re-render a whole component’s sub-tree.

With React, child components will all be refreshed each time application state is changed. This can be overridden by using the shouldComponentUpdate lifecycle method, but Vue.js handles this kind of optimization by default.

Component Based Architecture

Both React and Vue.js encourage a component based architecture. This essentially means separating your application into distinct chunks of related functionality with a defined way for each chunk to ‘talk’ to each other. A good explanation of what a component is can be found in this Medium article:

You can think of a component as a small feature that makes up a piece of the user interface. If I were to describe a component within the scope of Facebook’s UI, A chat window would be a component, a comment feed would be another component, and a constantly updating friend list would represent yet another component.

In Vue.js, you can use single file components that follow this principle.

//PastaItem.vue

<template>
<li class="pasta-dish list-unstyled">
    <div class="row">
        <div class="col-md-3">
            <img :src="this.item.image" :alt="this.item.name" />
        </div>
        <div class="col-md-9 text-left">
            <h3>{{this.item.name}}</h3>
            <p>
                {{this.item.desc}}
            </p>
            <button v-on:click="addToOrderNew" class="btn btn-primary">Add to order</button> <mark>{{this.orders}}</mark>
        </div>
    </div>
</li>
</template>

<script>

export default {
    name: 'pasta-item',
    props: ['item'],
    data:  function(){
        return{
            orders: 0
        }
    },
    methods: {
        addToOrderNew: function(y){
            this.orders += 1;
            this.$emit('order');
        }
    }
}

</script>

<style src="./Pasta.css"></style>

As you can see in the above example HTML, JavaScript and CSS are combined in one file. You don’t have to include CSS in your component .vue files, but it’s an option.

In React it’s very similar, with JavaScript and that fun JSX markup in a component file.

import React from "react";

class PastaItem extends React.Component {

    render() {
        const { details, index } = this.props;

        return (
            <li className="pasta-dish list-unstyled">
                <div className="row">
                    <div className="col-md-3">
                        <img src={details.image} alt={details.name} />
                    </div>
                    <div className="col-md-9 text-left">
                        <h3>{details.name}</h3>
                        <p>
                            {details.desc}
                        </p>
                        <button onClick={() => this.props.addToOrder(index)} className="btn btn-primary">Add to order</button> <mark>{this.props.orders || 0}</mark>
                    </div>
                </div>
            </li>
        );
    }
}

export default PastaItem;

Props

As in the above example, both React and Vue.js have a concept of ‘props’, which is short for properties. These are special attributes on an element that allow for the passing of data from parent to child.

Object.keys(this.state.pastadishes).map(key =>
    <PastaItem index={key} key={key} details={this.state.pastadishes[key]} addToOrder={this.addToOrder} orders={this.state.orders[key]} />
)

In the above JSX example the index, key, details, orders and addToOrder attributes are props passing data to the child PastaItem component.

In React this is necessary as it relies on a local ‘state’ (more on that later) that acts as a ‘single source of truth’.

In Vue.js, props are slightly different. They’re defined on a component in the same way, but since Vue.js relies on a template syntax – you have to use the built-in template loop functions.

<pasta-item v-for="(item, key) in samplePasta" :item="item" :key="key" @order="handleOrder(key)"></pasta-item>

It’s a little more on the ‘templatey’ side of things, but it gets the job done and I find it about as complex as the React version.

Build Tools

Both React and Vue.js have bootstrap applications that get you up and running quickly with your development environment. In React this is Create React App (CRA) and in Vue.js it’s vue-cli. In both cases you get a project template set up according to the latest best practices.

With CRA you’re a little more handcuffed as far as options. It’s an opinionated tool, forcing you to use Webpack and Babel out of the box. With vue-cli, you have options in the form of templates which makes it a little more flexible.

Chrome Devtools

Both React and Vue.js also have awesome Chrome extensions to help in debugging. They let you inspect your application as you would any other website, but they allow you to see the Vue.js or React version of the markup. You’re also able to see application state data and see updates happen in real time.

React devtools in action:

Vue.js devtools in action:

Companion Frameworks

One last similarity (and difference) between these two frameworks is how they handle companion frameworks. Both React and Vue.js are focused solely on the UI layer, and leave functionality such as routing and state handling to companion frameworks.

The difference between Vue.js and React is how they relate to their respective companion frameworks. The Vue.js core team maintains the vue-router and vuex frameworks and keeps them under the main Vue umbrella. React’s react-router and react-redux are maintained by community members and aren’t ‘officially’ under the Facebook/React umbrella.

Main Differences

While Vue.js and React have a lot in common, there are some major differences.

Templating vs JSX

The biggest difference between React and Vue.js is how templating is done. In Vue.js, you’re encouraged to use regular-old-HTML for templating. This approach leverages custom attributes on standard HTML elements.

<ul>
    <template v-for="item in items">
        <li>{{ item.msg }}</li>
        <li class="divider"></li>
    </template>
</ul>

The attributes can also be used on single file components, although it requires a build step to convert the component syntax to valid JavaScript and HTML.

<ul>
  <pasta-item v-for="(item, key) in samplePasta" :item="item" :key="key" @order="handleOrder(key)"></pasta-item>
</ul>

Vue.js encourages the use of HTML to render things, while it uses a familiar Angular-style method for outputting dynamic content with Mustache-style syntax. For this reason, Vue.js is arguably easier to integrate into existing applications as you can very simply incorporate Vue.js templates into existing templates without too much overhead. This also reportedly makes it easier for newcomers to adapt to this syntax.

React on the other hand recommends you write all your template code in JavaScript by using a ‘syntax extension to JavaScript’ called JSX. For example, the same code in JSX:

<ul className="pasta-list">
    {
        Object.keys(this.state.pastadishes).map(key =>
            <PastaItem index={key} key={key} details={this.state.pastadishes[key]} addToOrder={this.addToOrder} orders={this.state.orders[key]} />
        )
    }
</ul>

React/JSX definitely appears more verbose at first glance, but by adding the ability to use JavaScript within templates a lot more power is given to the developer.

But remember:

With great power comes great responsibility. Ben Parker

JSX is really just JavaScript with some funny XML syntax. However, once you get used to it, it feels a lot more flexible and robust. This might be my own biases coming through, but I feel this is a better approach as I was never a fan of the Angular 1 style attribute mess.

The counter argument is that Vue.js’ template syntax removes the temptation to pile additional logic into your views/components, maintaining a separation of concerns.

It should also be mentioned that Vue.js does technically support render functions and JSX, like React, but they’re not the default approach.

State Management vs Object Properties

If you’re familiar with React you’ll know that application state is a key concept. There are even frameworks dedicated to managing large scale state objects like Redux. Additionally, state data in React applications is immutable, meaning that it can’t be changed directly (though this isn’t exactly true). In React you need to use the setState() method (or the useState() hook) to modify anything in the local state.

 addToOrder(key) {
        //Make a copy of this.state
        const orders = { ...this.state.orders };

        //update or add
        orders[ key ] = orders[ key ] + 1 || 1;
        this.setState( { orders } );
 }

With Vue.js a local state object isn’t required, and data is managed via the data property on the Vue object.

export default {
  name: 'app',
  data() {
    return {
      samplePasta: samplePasta,
      orders: {}
    }
  },
...
  methods: {
    handleOrder: function (key) {

      if (!this.orders.hasOwnProperty(key)) {
        this.$set(this.orders, key, { count: 0 });
      }

      this.orders[key].count += 1;
    }
  }
}

In Vue there’s no need to call a state management function like setState(), as the data parameter on the Vue object acts as the holder for application data.

On the topic of state management for large scale applications, Evan You, creator of Vue.js, has said that these kind of solutions are suitable for small scale applications, but are not scalable for larger applications.

In most cases, the built-in state management patterns provided by the frameworks themselves are insufficient for large scale apps, and a dedicated solution like Redux or Vuex must be used.

With that in mind, arguing about how state is managed in your application is most likely a premature optimization, and, as with most things, it’s a matter of personal preference. Besides, you might not even need to worry about it.

React Hooks

One of the bigger updates to React in 2019 was the addition of Hooks in React 16.8. Hooks are a big deal because they introduced stateful functional components. This means that you no longer have to use the ES2015+ class syntax to create components and you can use the much less verbose functional syntax.

For example, here’s the minimum amount of code to create a component using the class syntax:

class MyComponent extends React.Component {
    constructor() {
        super();
        this.state = {
            someStateValue: true
        };
    }

    handleClick = event => {
        this.setState({
            someStateValue: !this.state.someStateValue
        });
    };

    render(){
        return (
        <>
            <p>React Class test</p>
            {`state: ${this.state.someStateValue}`}
            <p>
            <button onClick={()=> this.handleClick()}>Toggle state</button>
            </p>
        </>
        );
    }
}

ReactDOM.render(
    <MyComponent />,
    document.getElementById('root')
);

And with hooks:

const MyComponent = props => {
    const [someStateValue, setSomeState] = React.useState(true);

    return (
        <>
            <p>React hooks test</p>
            {`state: ${someStateValue}`}
            <p>
                <button onClick={() => setSomeState(!someStateValue)}>
                Toggle state
                </button>
            </p>
        </>
    );
};

ReactDOM.render(<MyComponent />, document.getElementById("root"));

As you can see, with the functional syntax, not only is there less overall code, but it’s much easier to see what’s going on. The biggest addition in hooks is the addition of new built-in hooks like useState() and useEffect().

useState() is the Hooks method to manage state in a component. Rather than use this.setState(), you destructure two variables from the useState() method. The first variable is the state property and the second variable is the ‘setter’ function.

For example, in the above code we have const [someStateValue, setSomeState] = React.useState(true);. someStateValue is the state value we’ll use in our component and setSomeState is actually a function we’ll call when we want to update our state.

See the Pen React Hooks example by Peter (@tasker82) on CodePen.

The other big enhancement with hooks is that class ‘lifecycle’ methods are replaced with one useEffect() hook. It handles all the ‘componentDidMount(), componentWillUnmount() etc.’ jank.

As per the React docs, previously if you want to do something when a component ‘mounted’ (was added to the DOM), and when a component was updated, you would have to use the two different methods:

componentDidMount() {
    document.title = `You clicked ${this.state.count} times`;   
}

componentDidUpdate() {
    document.title = `You clicked ${this.state.count} times`;
}

With the useEffect() hook, you have one function that handles both cases:

useEffect(() => {
    document.title = `You clicked ${count} times`;
});

The useEffect hook is a lot more powerful than this simple example, with support for running actions when components unmount (replacing componentWillUnmount) as well as limiting effects to only run when certain values don’t change between renders.

The other neat part of hooks is that you can create your own custom hooks. This allows you to ‘extract component logic into reusable functions’. What this means is that you can reuse state and lifecycle management code throughout your app, just like reusing components.

Vue 3 – Composition API

So does Vue.js have anything like React’s hooks? Vue 2.x doesn’t but Vue 3 is right around the corner. One of the new features in version 3 is something called the Composition API. Before we go any further, I should mention that Vue 3 is in the ‘pre-alpha’ phase, so some of this may change once version 3 is officially released.

Some of the reasons Hooks were added to React are valid for Vue.js as well. Vue.js typically has a simpler API, separating out data and computed properties. What can happen in large applications is that this simpler interface can make it difficult to create reusable code. Developers can end up creating massive components that are hard to reason about – just like React classes!

Let’s take a look at some Vue 2 code:

<template>
    <div>
        <h3>Vue 2 test</h3>
        <h3>Hungry? {{ hungry }}</h3>
        <h3>Eating? {{ setEating }}</h3>
        <button v-on:click="updateEating">Toggle</button>
    </div>
</template>

<script>
export default {
    data() {
        return {
            hungry: true
        };
    },
    computed: {
        setEating: function() {
            if (!this.hungry) {
                return true;
            }
            return false;
        }
    },
    methods: {
        updateEating: function() {
            return (this.hungry = !this.hungry);
        }
    }
};
</script>

In this super simple example, you can see how we’ve got three distinct methods to keep track of: the data(), computed() and methods(). We’re also sort-of relying on the pseudo-class based interface syntax by referencing instance variables using the this keyword. In version 3 of Vue.js, all this data can be colocated in the same method.

Note: To use the Vue 3 Composition API you need to add the @vue/composition-api package and add it to your Vue.js project.

<template>
<div>
    <h3>Vue 3 test</h3>
    <h3>Hungry? {{ hungryState.hungry }}</h3>
    <h3>Eating? {{ setEating }}</h3>
    <button v-on:click="updateEating">Toggle</button>
</div>
</template>

<script>
import { reactive, computed } from '@vue/composition-api'

export default {
    setup() {
        // Pet name
        const hungryState = reactive(
            {
                hungry: false
            }
        );

        const setEating = computed(() => {
            if (!hungryState.hungry) {
                return true;
            }
            return false;
        });

        const updateEating = () =>{
            return (hungryState.hungry = !hungryState.hungry);
        }

        // All properties we can bind to in our template
        return {
            hungryState,
            setEating,
            updateEating
        };
    }
};
</script>

In the above contrived example we see how things can be combined into one setup() method. This allows for a more tightly coupled set of code and simplifies reusability a bit more. In the Vue 3 RFC for the Composition API, there are two main reasons this organization method:

The code of complex components becomes harder to reason about as features grow over time. This happens particularly when developers are reading code they did not write themselves. The root cause is that Vue.js’ existing API forces code organization by options, but in some cases it makes more sense to organize code by logical concerns.

Lack of a clean and cost-free mechanism for extracting and reusing logic between multiple components.

Like React Hooks, the Vue 3 Composition API is opt-in, with the legacy Options API still supported.

Static Site Generators

The next biggest thing to come into the React world in the last couple of years is static site generators, in particular Gatsby. It seems that out of nowhere JS-based static site generators have become a big deal – this is especially true of Gatsby.

If you’re not familiar with Gatsby, it’s essentially a build system that relies on React and GraphQL to create static HTML files. I wrote about Gatsby previously, and I wondered if Vue had a similar tool. Turns out, it does – Gridsome. I haven’t had the chance to try out Gridsome, but it looks like a Vue flavored Gatsby. Just like Gatsby, you can specify multiple content sources (APIs, headless CMS’), use GraphQL to define content queries, write content in Markdown, and build new sites from a premade starter template.

Judging by the feature list of Gridsome, it appears that it has just about reached feature parity with Gatsby. The biggest issue I see with something like Gridsome is overcoming the popularity of Gatsby. Judging entirely by the superficial metric of Github stars, Gridsome has 5.6k while Gatsby has ~9x that with 42.6k. This gets into the next point – market share.

In 2020, few would argue that React is the top JavaScript framework in terms of popularity. Good or bad, it seems React is here to stay. Because of its popularity, there is plenty of documentation and tutorials for React available online.

A side-effect of a large market share is development speed. React shipped React Hooks in Feb 2019, while Vue 3 is in the early alpha phase as of writing this post. Now, I hear you say “But React is backed by Facebook, a huge corporation!?!” This is true, so there may indeed be more people working on React, speeding up development.

All that to say, React will continue to dominate the front-end framework landscape for the time being. This is especially true for the WordPress editor as it’s built entirely with React and related frameworks.

With this popularity, it’s also worth talking about jobs and career prospects. React jobs seem to be more in demand, pay the most, and seems to hold a large chunk of developer mind-share. But as with everything, it changes over time 🙃. All that said, career growth is something worth thinking about if you’re considering picking up either React or Vue.js.

Bottom Line

So there you have it, a ‘sort-of-thorough’ overview of React and Vue.js. There are plenty of things not discussed here, but this should give you a pretty good starting point to get up to speed with either framework.

I do think however, now more than ever React is the most popular front-end framework out there. The growing fanfare around Gatsby as well as React ruling mobile (React Native and desktop (Electron) only highlights this popularity.

Vue.js seems to be taking a lot of the concepts developed in React and refining them and making them better. Some would argue Vue.js has a less steep learning curve. It seems to be very popular in the Laravel community, and I think the release of Vue 3 will be a big deal for Vue.js fans. I would argue that Vue.js has a strong community, it’s just not at the same level as React.

We are also starting to see new frameworks that take what works in React and Vue.js and make them better. One example is Svelte. Svelte doesn’t use virtual DOM diffing to make updates to the UI, but ‘…writes code that surgically updates the DOM when the state of your app changes.” I think Svelte is something to keep an eye on as devs like myself are becoming allergic to complexity!

Calling all React developers and Vue developers, what do you think are the best features of React and Vue.js? Which one do you prefer? Let us know in the comments.

This entry was posted in WP Migrate DB Pro, Code and tagged WordPress, Development, Code, React, Vue.js, JavaScript, controversial.

.replybox-fallback, .replybox-fallback ul { list-style: none; }

Alex Standiford says:

June 19, 2017 at 1:28 pm

I’m just waiting for more-educated WordPress contributors to make their choice. Whatever they choose is what I’m going to go with. I have been reluctant to learn a modern JS framework because the network has felt too volatile for me to make a jump, and I really don’t see a point in learning something until I decide to use it in my daily workflow. I invest my time in getting really good at the tools I use instead of pretty good at a bunch of different tools. Once the community makes this decision, I have a solid reason to learn one of these frameworks. Until then, I’ll just stick with jQuery, even though I dislike it.

Nocare says:

June 19, 2017 at 2:49 pm

Responsible use of jQuery and WordPress itself is plenty. Too often I see people go off the deep end with front end frameworks and get nothing useful done in a timely manner. On smaller scale sites the biggest performance hits are going to come from bad or bottlenecked in code. A framework can’t really fix that as stupid/lazy always finds a way. There is a new hot framework and 5k "vs" blog posts every 6 months anyway. Over engineering sells well right now I guess.

Reply
- Alex says:
  
  August 1, 2017 at 2:29 pm
  
  That’s kind of where I’m at most of the time. I don’t need much more than a few quick jQuery manipulations for most of what I do, but every once in a while I do.
  
  Reply
Peter Tasker says:

June 20, 2017 at 10:29 am

Sounds like at WCEU a decision was made, so I’m guessing the announcement will be out soon.

Reply
jamesorodig@gmail.com says:

June 20, 2017 at 11:57 am

The counter to this is that a number of the frameworks share concepts that are broadly applicable. Understanding what a component is applies to React, Vue, Angular and others. The knowledge transfers, even if the specific implementations are different between them, so there isn’t a reason to avoid learning one. Understanding React makes learning Vue easier, and gives you a better sense of what trade-offs are made when choosing one over the other. Also, many of these frameworks follow a similar Flux-y pattern (actions up, data down), which is additional knowledge that again transfers regardless of framework. The volatility in the JS community has settled down since a few years ago, and these concepts are broadly applicable, so I’d highly recommend picking one (usually React) and learning it as much for its concepts/approaches as its specific implementation.

Reply
- Alex says:
  
  August 1, 2017 at 2:27 pm
  
  You’re certainly not the first person to counter with that :), and your points are valid.
  
  Reply
John Furr says:

December 31, 2017 at 8:55 am

I am similar to you. However I decided to try and use Vue on hobby project… then I decided to try and remove jQuery (as a learning exercise). This was about as painless of a process as I could image. To be blunt once I was able to change the data and see the html change in real time I finally ‘got’ it. The superiority of this kind of model vs directly updating the DOM with something like jQuery was pretty obvious to me. Now flash forward a few weeks and I have slowly started to adopt more front end tools and slowly inch my way into the modern JS world.. and I didn’t have to start a new project from scratch to do this. In all honesty I encourage all jQuery developers to spend 1 hour with the Vue docs..and then to try including the vue script tag into their project. I’m guessing most will fall in love like I did.

Reply

boydbme says:

June 19, 2017 at 1:29 pm

Getting on a plane tonight to head out to Poland for VueConf 2017. I’d be absolutely stoked if Vue was encouraged as a default in WordPress setups. We’ve already completed a few projects where the front-end was a Vue app talking to a headless WordPress install via the JSON api. Combines the best of reactive front-ends with an easy dashboard for clients to manage data.

electronicpakrat@gmail.com says:

June 19, 2017 at 4:39 pm

If WordPress.org wants to increase the number of developers that can quickly get up to speed with core contributions, theme and plugin development, etc they should choose Vue. Doing otherwise seems like it’s just creating an unnecessary barrier to entry. As they’re already familiar with React, they may be blind to the negative ramifications of using it over Vue if there’s any significant bias already present. I must give them credit though for putting the choices out there even if choice itself is an illusion in the end.

Peter Tasker says:

June 22, 2017 at 9:54 am

I think the decision on which framework to use in WordPress core is really the only decision being made. You don’t have to use Vue/React in your own themes and plugins. Those are still open. Does anyone use Backbone in their themes/plugins? But I do agree that adding whichever framework will increase the barrier for entry, and I think one of the things the core-js team is planning on doing is increasing the documentation and quick starts. Something I’m planning to contribute to as well! What kind of negative ramifications do you think there’ll be by choosing React?

Reply

jamesorodig@gmail.com says:

June 19, 2017 at 10:42 pm

Be careful with code that dynamically add keys to objects in Vue: if (!this.orders.hasOwnProperty(key)) { this.orders[key] = {count:0}; } This actually won’t get tracked properly by Vue’s reactivity system. Vue bootstrap’s the component’s data and registers getters & setters on all of the properties currently on the object. Because this is adding a new key to the object, it’s not tracked by default. In order to make sure it gets tracked, add it like this: if (!this.orders.hasOwnProperty(key)) { this.$set(this.orders, key, {count:0}); }

Peter Tasker says:

June 20, 2017 at 10:17 am

Good catch @JamesDiGioia:disqus! Being a newbie to Vue I assumed that since the top level object key was already attached to the Vue object, nested objects would also be reactive. For anyone wondering, more info on reactivity can be found in the Vue docs: https://vuejs.org/v2/guide/reactivity.html#Change-Detection-Caveats

Reply
- jamesorodig@gmail.com says:
  
  June 20, 2017 at 11:05 am
  
  This has messed me up so many times when developing in Vue that it’s really turning me off to their reactivity system, especially coming from Redux where I’m so used to creating new objects. Mutating objects feels foreign and wrong, and mentally tracking whether keys exist on the object is a layer of mental overhead I’m not a fan of.
  
  Reply
  - Peter Tasker says:
    
    June 20, 2017 at 11:09 am
    
    Yep same here. Thinking in React vs Vue is soooo different. Local state objects vs object props does feel a bit backward.
    
    Reply

Jon says:

June 20, 2017 at 12:25 pm

First, this is an awesome comparison piece, thanks for contributing it! I keep reading these and the more I talk to people (all over WCEU) my opinion becomes firmer that Vue is the better choice, but that neither is bad choice. In which case a quick decision is probably better for the project than a slow one. Personally, my JS novice brain finds Vue way more accessible and easy to understand as I read it. Vue also seems much easier to integrate with WordPress’ historic methodologies, and it really just makes more sense to me out of the box. As I talk to people it’s clear Vue has a lot of vocal supporters, whereas React has a lot of quiet supporters. While the "powers that be" do seam to be sincerely entertaining Vue, it does seem a foregone conclusion it’s going to be React from those "deciders". I haven’t heard many arguments for React beyond "it’s what we know", "it’s more mature" and "react native is awesome". None of those seem key to me. Vue is easy to learn, honestly pretty mature on it’s own, and "native" doesn’t really matter to WordPress. The thing that bothers me is hearing that the decision core makes isn’t going to affect or limit plugin and theme developers… it absolutely does in a huge way. I get that a bunch of important core people already jumped on the React bandwagon (Automatticians, Yoast, Human Made and some others). However, I still feel like that isn’t an important factor. Learning and training is easy compared to deprecating and changing things WP. Decisions should be weighed on what is best for everyone over the next 10 years. For every argument there is an equally valid counter argument… Either choice will work out ok, but a quick decision would serve everyone better than this dragging on for months or years like so many key decisions in WP core seem to…

Thiago Cangussu says:

July 20, 2017 at 1:38 pm

I don’t know why people keep pretending there is a decision to be made about what libray will be used by WordPress core. Gutenberg have been built with React. They already made the decision. Why would they choose Vue now? Nobody will recode Gutenberg using Vue and load 2 libraries is just insane. So they will keep React.

Reply
- Glenn Martin says:
  
  September 19, 2017 at 3:06 pm
  
  https://ma.tt/2017/09/on-react-and-wordpress/
  
  Reply
  - Max Hodges says:
    
    November 25, 2017 at 12:04 pm
    
    https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/
    
    Reply

DeryckOE says:

June 20, 2017 at 4:07 pm

Hi Peter, there is broken link on post. There is a missing "i" on https://github.com/vuejs/vue-cl Great post, by the way.

Peter Tasker says:

June 20, 2017 at 4:24 pm

Right you are! Fixed.

Reply

Oli101 says:

June 21, 2017 at 9:10 pm

I’ve been learning React.js for a few weeks and it’s actually not that hard to pick up. It’s just JavaScript after all so if you take the time to learn JavaScript then you will learn React fairly quickly. I’ve never used Vue.js but from what I’ve read Vue is pretty easy to learn. I’m not really fussed as to which JS library the WordPress core team decide to use but they need to make a decision soon so we all know which library to invest our time in learning.

Peter Tasker says:

June 22, 2017 at 10:00 am

Yep, I had the same thoughts, I recently learned Vue and had the same feeling as when I learned React a couple years back. Same kind of thing and the documentation in both cases in fantastic.

Reply

Jon says:

June 22, 2017 at 10:09 am

I don’t get why people keep saying "developers will still be able to use whatever they want". The WordPress way has always been to use Core APIs whenever possible. If there is a core API that creates a settings/metafields/post editor boxes/etc… then I’m not going to use that AND modify or extend that same page with Vue. One would assume at some point the left sidebar in the admin get some SPA style love, so anything wrapped with that chrome will either load both (insane) or be built with what core uses (sane).

Jon says:

June 22, 2017 at 10:10 am

^ as a plugin dev… but as a theme dev it’s the same thing, I’m not going to build a theme based on Vue and then build the backend in React to match core… it’s going to be all the same.

Reply

Fez Vrasta says:

July 1, 2017 at 9:14 am

I wonder how do you plan to integrate Vue.js templates into an existing app without a build step since the Vue templates are compiled at build time AFAIK..

Peter Tasker says:

July 4, 2017 at 1:42 pm

If you’re using Single File Components you do need a build step, but regular Components can be just be defined as strings and registered. // registerVue.component('my-component', { template: 'A custom component!'})https://vuejs.org/v2/guide/components.html

Reply
Peter Tasker says:

July 4, 2017 at 1:47 pm

And also, you can use a tag to house Component templates as well! https://jsfiddle.net/yyx990803/mwLbw11k/

Reply

victor hazbun says:

July 23, 2017 at 12:32 am

Vue > React, why? Short learning curve, simple to code, great docs, if you are angular (1) developer it’s a big advantage because they are really similar.

Matthew says:

July 29, 2017 at 3:36 pm

"if you are angular (1) developer" – hahaha. Truth be told, vue.js has already surpassed react.js in actual use/adaptation because many developers have abandoned angular & jumped to vue.js. With virtually nothing to learn, even developers who have no prior Angular experience can build things quickly on vue.js and the chart below clearly shows this to be true. https://w3techs.com/technologies/comparison/js-react,js-vuejs react.js is a total mess to maintain. if you need to make just one css change, you can’t just change the css file in react.js. Shits about to hit the fan & most ppl, including Automattic, are clueless as to what they’ve got into. react.js will increase development & maintenance cost beyond imagination for companies that decide to use it; not sure if that’s a good or bad thing for developers though. Lastly, react.js is not open source. FB can shut your project down if FB likes it & wishes to steal your product. This won’t affect small guys/companies but Automattic doesn’t seem to understand this.

Reply

beck6456 says:

August 4, 2017 at 6:17 am

Every java programmers are like this post and i think it will be great tips for them. To get more better suggestion from here they need to read this kind of article in here regularly.

chris marx says:

September 4, 2017 at 12:37 am

Angular 2/4 does everything mentioned here, I think it’s time to consider it as well

Barry Tester says:

October 5, 2017 at 5:20 am

I came from angularjs to angular 2 – and the pain of constantly changing to accommodate the mercurial nature of the angular dev team as they worked through to version 4. After picking up Vue and migrating the entire project in 6 weeks (which included learning Vue) – I won’t use Angular again. It’s too prescriptive and the sheer amount of scaffold required, even with Typescript (which I miss a little bit) just makes it not worth the pain and effort

Reply
- chris marx says:
  
  October 5, 2017 at 12:46 pm
  
  Where you using the angular cli? Since the cli, there is zero scaffolding-
  
  Reply
  - Barry Tester says:
    
    October 6, 2017 at 4:03 am
    
    Yeah I used that. It probably would’ve been better if I’d had it set up for single-file components, rather than it crapping out 4 files for each component – the project folder was huge. Maybe I’ll take another look at Angular when I’ve a large enterprise project and Angular is stable, as I was at the bleeding edge – the C# devs I mentored really liked Typescript… but for me, .vue single-file templates with pug instead of HTML is awesome – I’m trying to write as little code as possible, and this makes me super-productive 🙂
    
    Reply
PetrOdut says:

January 14, 2018 at 12:47 pm

Angular 2/5 is just terrible and TypeScript maybe is the best part of whole framework. There’s few reasons why I don’t like angular: 1) it’s verbose: you have to write a lot of code to define simple component 2) AOT is unpredictable and using Angular with old-school JIT compiler is painfully slow. Also converting older Angular 2 project to AOT is super stressful — causes unpredictable, not documented errors. Google doesn’t help much. 3) Angular adds custom component element into the dom. It’s super dumb when creating some layout and suddenly you have more elements which is breaking your layout. Only way to figure out is to use component selectors like which looks like directive and event binding is not working as you expected 4) When you start exploring Angular 2/5 more deeply you will discover more and more inconsistencies. Where React and Vue do the great job Angular is unpredictable and buggy.

Reply
- chris marx says:
  
  January 15, 2018 at 3:17 pm
  
  There were some growing pains wth AOT, but I think the dust has settled now. AOT also adds value, and libraries like react aren’t even doing it yet. I don’t know why you’d take issue with custom components, it mimics the web-component spec and afaik, we’re all just waiting for web-components to become a reality everywhere-
  
  Reply
  - PetrOdut says:
    
    January 15, 2018 at 5:12 pm
    
    > and libraries like react aren’t even doing it yet React and similar libraries do this by default (JSX to JS is default compilation (transpilation) step). AOT just precompiles string templates to JS, which saves some computing power during the app boot (and I know that it significantly speeds up the app boot). Web-components are unfortunately still future. I also believe that the spec needs to be improved to go really mainstream. Therefore mimic incomplete technology is not wise idea. React’s (and Vue’s) approach is not to include component tag in the dom, just the content inside render function. So when you are working with some CSS framework, you don’t suffer with some extra elements in the dom which breaks flexbox etc.
    
    Reply
    - chris marx says:
      
      January 16, 2018 at 12:30 pm
      
      Nope, we’re not just talking templates here. Yes, jsx takes care of that, but aot does more than just precompiling string templates: https://github.com/reactjs/react-future/issues/50 Also, for most people, who are just doing a complete app in angular, they’re using flexbox within the custom element itself, and I’ve had no problems using flexbox there. You can also wrap the custom element in a flexbox div, or add css styles specifically for the element, these seem like very small issues-

Sadegh hp says:

September 6, 2017 at 1:00 am

what about aurelia ?

James J. Ye says:

December 26, 2017 at 10:49 am

Thanks for the post! Just want to point out that Weex is very much battle tested during the 11.11 event of Taobao and Tmall in China. https://weex.apache.org/ https://en.wikipedia.org/wiki/Singles%27_Day

Jeff Cleverley says:

December 29, 2017 at 3:52 am

Yeah, I hate seeing this misinformation being spread around as an advantage for React/React Native when it is just not true at all. I don’t think any React Native app has been as battle tested as the TMALL/Taobao app. I would certainly be interested if someone could provide an example.

Reply

Merovech says:

March 22, 2018 at 3:04 am

In a recent study conducted on various programming languages, Typescript had a higher likelihood of bugs in the code than Javascript. Just putting it out there… http://www.i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html

Mark Truitt says:

June 13, 2020 at 9:28 am

I honestly don’t see the need. I write everything in ES6 with eslint running and have Babel transpile to ES5 for IE11 support. Works great and one less layer to worry about.

Reply

rogerdpack says:

July 19, 2018 at 7:52 pm

I’m confused, TypeScript over vue?

Bryan Keniry says:

March 17, 2020 at 6:38 am

Vue because of "inline-template" – you can use a backend rendering engine such as PHP, .NET, a CMS and output HTML (rather than having it in JavaScript) and use "inline-template" to connect Vue. React wants to control everything which makes it less flexible if you need some other code to generate the markup.

Josh Jarman says:

March 18, 2020 at 11:12 pm

I like Svelte the best but I think Vue is the most accessible and friendliest, and React has the most community momentum and support, i think the battle is determined by the question "by whom and for what?" For the general WordPress community, I think Vue would be an much easier learning curve.

Mark Truitt says:

June 13, 2020 at 9:27 am

Svelte is cool until you have to get it to work with IE11! For this reason I still stick with Vue until I can drop IE11 support.

Reply
- Josh Jarman says:
  
  June 13, 2020 at 2:45 pm
  
  Bable will transpile it just fine offering IE11 support if that is really still needed these days.
  
  Reply

Maq Said says:

April 19, 2020 at 12:46 am

React.js 16.8 made the development easier and it becames fun also. Hooks scalability makes developers updates the code with lesser steps. You done well with this blog thanks for sharing your thought with us. the community of developers love oyu all

Mark Truitt says:

June 13, 2020 at 9:25 am

It is interesting that Vue is playing catch up with React. Now there are hooks, fragments, and portals. I use Vue at work for several apps and I like how easily I can convert older Angular 1 apps to Vue. Looking forward to Vue 3 so I can have some of these nice React features.

Reply

Ernesto Jaboneta says:

April 6, 2021 at 2:18 pm

Great comparison article! Unfortunately, it seems Vue doesn’t get fair treatment. Most "coding bootcamps" have decided that React is the future so most new "full stack developers" only get introduced to React/Python and don’t care to explore alternatives. From a hiring standpoint, I have to make the decision to either have fewer candidates for a Vue project, or be forced to use React.

WP Migrate