DEV Community: Paul Shen

Comparing Vue and React

Paul Shen — Mon, 10 Aug 2020 15:54:10 +0000

As a React developer, I wanted to dive into Vue to learn how it approached building JavaScript UI. How do they differ? Is one better?

I'm using Vue 2 but have also spent some time looking at Vue 3. Please call me out on any inaccuracies 🙃

Let's start by looking at their taglines. React is "a declarative, efficient, and flexible JavaScript library for building user interfaces." Vue is "a progressive, incrementally-adoptable JavaScript framework for building UI on the web."

Very similar sentences with a few important differences. Just like the libraries themselves.

Highlights

At a high level, the frameworks take similar approaches to the same goal.
React is JavaScript-centric vs Vue uses hybrid HTML template/JS.
React uses a push update model vs Vue implements reactivity via observing.
Vue has more built-in. React is more barebones and relies on community.

Language approach

Let's jump right in and look at a pretty full-featured component. I'm going with the Vue 3 composition API because it seems like the direction Vue is heading. There are obvious parallels: the Vue component options API is to React class components as Vue 3 composition API is to React hooks.

// UserProfile.vue
<div>
  <div>{{ id }}</div>
  <Avatar v-if="showAvatar" :id="id" />
  <UserBody v-if="user" :user="user" />
  <button @click="$emit('follow-click')">Follow</button>
</div>

defineComponent({
  props: {
    id: { type: String },
    showAvatar: { type: Boolean },
  },
  setup(props) {
    const {id} = toRefs(props);
    const user = ref(undefined);
    function updateUser() {
      fetchUser(id.value).then(data => {
        user.value = data;
      });
    }
    onMounted(updateUser);
    watch(id, updateUser);
    return {user};
  }
})

// React
function UserProfile({id, showAvatar, onFollowClick}: {
  id: string,
  showAvatar: boolean,
  onFollowClick: () => void,
}) {
  const [user, setUser] = React.useState(undefined);
  React.useEffect(() => {
    fetchUser(id).then(setUser);
  }, [id]);

  return (
    <div>
      <div>{id}</div>
      {showAvatar ? <Avatar id={id} /> : null}
      {user !== undefined ? <UserBody user={user} /> : null}
      <button onClick={onFollowClick}>Follow</button>
    </div>
  );
}

I used to be quite allergic to HTML templates (e.g. mustache) because of their loose run-time nature. Back in the day, it was a bunch of string manipulation. However, in Vue (and Svelte and other modern frameworks), templates are processed at build-time into JavaScript. You can use Vue Template Explorer to see how Vue templates transpile to JavaScript.

React's JSX is just sugar for JavaScript.

In a way, you could also say that Vue's templates are also JavaScript sugar. However, the transform is more involved and Vue-specific.

Pros and Cons

One advantage of Vue's template syntax is that because it is more restrictive, the compiler is able to perform more optimizations, such as separating out static template content to avoid rerenders. React can do something similar with a Babel plugin but this is not common. Theoretically, I believe Vue could make more optimizations from template syntax.

A disadvantage with Vue templates is that there are times when JavaScript's expressiveness is sorely missed or even necessary. In those cases, Vue recommends using a render function, either via the more verbose createElement or JSX. An example I ran into is wanting a local variable inside a template loop. Translating between Vue template and JSX is a manual process. I think you probably need to be familiar with both template and JSX to be a Vue developer, in which case React's one approach seems better.

If you use React hooks, React components are just functions. All the logic lives inside this function. Vue separates the component definition from the template (or render function). Using the new Composition API above, the component definition is inside one setup function. This is a notable difference; React hooks are run on every render but setup is only run once on initialization. Vue sets up listeners (lifecycle and reactive values) whereas React specifies effects on each render.

Event Handling

Event handling is another example of the differing language approach. React has no special syntax; it's just JavaScript functions. Vue provides syntax for listening to and emitting events.

// MyVueComponent
<button @click="$emit('increment')">Increment</button>

<MyVueComponent @increment="methodName" />

// MyReactComponent
<button onClick={props.onIncrement}>Increment</button>

<MyReactComponent onIncrement={jsFunction} />

You can see here the differing approaches to events. React passes a JavaScript function to the component. Vue components emit events, which are identified as strings with associated data.

Static analysis

At a high level, React is better suited for static analysis, such as TypeScript. Its JavaScript-centric approach puts it closer to the language so most editor/tooling just works. I set up VSCode with Vetur (Vue's recommended tooling) and didn't get semantic langauge features (e.g. checking, autocomplete, go to definition) inside the Vue template. Note: I found Vetur has an experimental setting for "Template Interpolation Service" which adds a lot of these features but it still misses features like find references.

Some Vue features like named slots, events, and their props (React children equivalent) are too dynamic for full static analysis. For example, components can emit custom events but there isn't an obvious way to write out that contract.

Vue provides a global namespace although it is not always recommended. For example, you can register components by name to the global namespace. Vue plugins can inject global methods, properties, and mixins. Global namespaces, while convenient at times, play less nicely with tooling and scalable codebases.

Update model

The biggest functional difference between Vue and React is how they handle updates. Vue uses observables (via JavaScript Proxies or defineProperty) to implement reactivity. In short, it modifies data to track when properties are read or written. This allows for fine-grained dependency tracking; Vue knows which properties have been read so it can rerender and update views only when those properties change. This is smarter than a stock React.memo, which compares equality for all props.

In comparison, React uses a push update model. Rerenders are triggered by a function call somewhere (state update or reducer dispatch). When a React component updates, it will rerender all its children as well.

// MyVueComponent
<button @click="count += 1">{{ count }}</button>

Vue.extend({
  data: {
    count: 0
  }
})

function MyReactComponent() {
  const [count, setCount] = React.useState(0);
  return <button onClick={() => setCount(count => count + 1)}>{count}</button>;
}

The way I think of Vue's update model is as if all components were wrapped in React.memo and the equality function was a dynamic one that compared only props/state that were used on the last render.

Vue's update model is a lot like MobX. Your atoms are your props/data and you can also have computed properties. Note: Vue currently rerenders whenever data underlying a computed property changes, even if the computed property itself does not change. This feature would be really nice as this is hard to express in React using React.useMemo without creating a wrapper component.

Out-of-the-box, Vue performs more granular updates so Vue updates are more performant by default. Of course, React has React.memo but that requires understanding of closures and when to use React.useMemo and React.useCallback. Vue isn't off the hook though. Reactivity via injecting observables comes with its gotchas.

API surface area

It's hard for me to be objective because I have a lot more familiarity with the React API. However, I still feel that React has a smaller API and fewer React-specific concepts to learn (ignoring concurrent mode and time-slicing).

A number of things are more convenient in Vue. Here are a few examples.

v-model

Vue has sugar for two-way data binding. It's quite nice.

// MyVueComponent
<div>
  <input v-model="message" />
  <p>{{ message }}</p>
</div>

Vue.extend({
  data: {
    message: ''
  }
})

The following is quoted from the React docs: In React, data flows one way: from owner to child. We think that this makes your app’s code easier to understand. You can think of it as “one-way data binding.”

function MyReactComponent() {
  const [message, setMessage] = React.useState('');
  return (
    <div>
      <input value={message} onChange={e => setMessage(e.target.value} />} />
      <p>{message}</p>
    </div>
  );
}

Combining class names

Vue has special class and style handling. These properties get merged and also handle object maps and arrays.

// MyVueComponent
<div :class="my-class-name">Hello</div>

<MyVueComponent :class="{ active: isActive }" />

This is more tedious with React. There is nothing special about className. Most people use a third-party library (like classnames).

function MyReactComponent({className}) {
  return <div className={'my-class-name ' + className}>Hello</div>;
}

<MyReactComponent className={isActive ? 'active' : ''} />

Reactivity

I will add a mention here for Vue's reactivity. I found it magical but pleasant to use.

<button @click="count += 1">{{ count }}</button>

defineComponent({
  reset() {
    // This causes rerender
    this.count = 0;
  }
})

The fact that mutating what looks like a local variable causes a rerender is still a little beyond my comfort zone 🙂

Vue as a framework

React pitches itself as a library and Vue as a framework. The line is blurry but Vue does more out-of-the-box than React. Vue has transitions and animations built-in. It has blessed libraries for routing and state management (vuex).

React, as in the core React, focuses on only the rendering layer. The other pieces are provided by the ecosystem, which fortunately, is very vibrant.

With my limited experience, bootstrapping an app feels about the same both with vue-cli and create-react-app. I like Vue Single File Components, which allows you to define component-scoped CSS in the same file as the template and component logic.

Not too different

While I've been spending time on the differences, they have many similarities. They are both web UI view libraries and a lot of the concepts map from one to the other.

Both use virtual DOM and support JSX
Vue slots and React children
Vue props/data and React props/state
Vue teleport and React portal

Which one should you use?

You probably expected this coming but I'm not going to give you a definite answer. It depends! You can be successful and productive with either one.

If you are a stickler for correctness and love type systems (which I am one), you will probably prefer React. It works better with TypeScript and has a purer language approach. Vue has a global namespace (although you can mostly avoid it) but features like custom events, plugins, and mixins embrace the dynamic nature of JS. For this reason, I would favor React in complex apps in large codebases with many engineers.

If you like the idea of starting with HTML/static content and sprinkling on JavaScript, then you might like Vue's template approach. Many websites really are of this nature, static content with some interactivity.

For developers less familiar with JavaScript, Vue is probably easier to get started with. Templates are intuitive and are incrementally adoptable. You don't need to think about rerendering and data-binding is easy to understand. This isn't to say that you can't build complex apps with Vue. If you spend a lot of time with JavaScript, you might like React's more pure language approach.

Finally, it's hard to ignore React's mass adoption and large ecosystem. For companies, React would be the less risky choice. More engineers have React experience than Vue experience; hiring will likely be easier. Also, there are more alternative React render targets, like React Native, that you may find useful.

At the end of the day, you can be productive with both frameworks. I personally still prefer React but I can't say it's strictly better.

VSCode with Vim tips

Paul Shen — Sun, 28 Jun 2020 17:20:15 +0000

My go-to editor of choice today is VSCode with the VSCodeVim extension. I won't go into why VSCode and Vim are great 😄. Instead, here are some tips for Vim users in VSCode.

VSCodeVim is a community VSCode plugin that adds good (though not perfect) Vim emulation. It also includes a few popular Vim plugin features. Overall, I'm quite happy with this combination. My main gripes are with performance and responsiveness (compared to Vim) but the extra VSCode features are well worth it for me.

It's worth scrolling through the VSCodeVim README, which is packed with features. Here are some of my favorites.

VSCodeVim Tricks

The VSCodeVim tricks section includes g d (go-to definition) and g h (show hover tooltip). Note that you can often mix-and-match VSCode shortcuts. For example, I use ⌘ + d (VSCode shortcut to add next search selection) instead of VSCodeVim's g b. I usually follow multiple selections with c to change the selections.

Many of VSCode features are built for mouse navigation. Some of these includes ⌘ + click, ⌥ + ⌘ + click, etc. With Vim, we want to stay on the keyboard as much as possible. I recommend browsing the keyboard shortcuts editor and adding your own keymaps. One of my favorite commands is editor.action.revealDefinitionAside, which opens the definition of the current symbol under your cursor in a split. I map this to g D.

{
    "vim.normalModeKeyBindings": [
    {
      "before": ["g", "D"],
      "commands": ["editor.action.revealDefinitionAside"]
    },
  ]
}

Easymotion

VSCodeVim comes with built-in easymotion! If you're not familiar with the Vim plugin, easymotion shows markers for Vim motions, allowing you to jump to a target. The ones I use are search by two characters and start of line forwards and backwards. To turn on this plugin, set the VSCode setting "vim.easymotion": true

I use easymotion A LOT, pretty much for any motion that isn't on the same line. I map s to easymotion 2 char and ⌃ + j ⌃ + k to easymotion line forwards backwards, respectively.

"vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["s"],
      "after": ["<leader>", "<leader>", "2", "s"]
    },
    {
      "before": ["<C-j>"],
      "after": ["<leader>", "<leader>", "j"]
    },
    {
      "before": ["<C-k>"],
      "after": ["<leader>", "<leader>", "k"]
    }
]

Semantic selections

Did you know that VSCode has semantic selections? You can expand and shrink your text selection powered by the language service (e.g. TypeScript). It almost works with VSCodeVim with the caveat that you need to press v before inputting your action, even though it already looks like a visual selection.

It's worth noting VSCodeVim has its own expand motion a f but it is not semantic. However, it does the right thing 90% of the time and may be worth using as your default because of the tighter integration.

Surround

vim-surround emulation is worth a mention. It provides operations to work with surrounding characters like parentheses, braces, quotes, etc. If you are working on web frontend, it makes it easy to wrap things with XML tags.

S [desired char] will wrap your visual selection. A common operation I perform is select a chunk of text in visual mode and then type S <div> to wrap it in a div tag (obviously replace with tag of choice). You can even type attributes S <div className="foo"> but the input is hidden until you close the tag. Similarly, wrap with S { S ( etc.

Editor tips are never comprehensive but I hope you found something to add to your toolkit. Tell me your favorites!

Will this work in React Concurrent mode?

Paul Shen — Tue, 25 Feb 2020 02:25:43 +0000

React Concurrent is the exciting next big thing for React. It touts performance benefits and ergonomic ways to implement render-as-you-fetch applications.

Opting into concurrent mode forces developers to think about React differently than they might have. Existing code that worked fine in today’s React may not work in Concurrent mode.

While React Concurrent mode is not ready for primetime, we have enough information to prepare and make sure our code and patterns support it.

A component’s render is no longer coupled with a host (DOM) update.

This is the biggest change to understand to make sure our components work with Concurrent mode. We need to make sure our render functions do not have side effects. This includes operations like updating refs, adding event listeners, and logging.

A render call does not mean that the result will be output to the DOM. The update may not show up for a period of time (could be arbitrarily long) or even ever. We'll see below how this is possible.

Reactive, the customer support team

To illustrate this, we'll use Reactive, a fictional customer support team that uses a React-like API for handling support tickets.

When the Reactive team is ready for more tickets, they call your render function to add your ticket to the queue. When your ticket is resolved, you want to tweet and thank the team.

function MySupportTicket() {
  // INCORRECT
  API.tweet("My address is changed! Thanks!");
  return <Ticket action="changeAddress" city="Venice, CA" />
}

Most of the time, Reactive is very responsive and processes your ticket immediately. In React, this is equivalent to updating the DOM immediately after render is called. Prior to Concurrent mode, this was how React always worked.

When Reactive got upgraded with concurrent powers, it gained more liberty with when to process support tickets. Reactive may hold off on processing your ticket because there are more urgent tickets to handle. There's no guarantee as to when your ticket will get processed. This is why we need to move the API.tweet call into an effect.

function MySupportTicket() {
  useEffect(() => API.tweet("My address is changed! Thanks!"));
  return <Ticket action="changeAddress" city="Los Angeles" />
}

React with Concurrent mode is similar. React can pause work to handle more important updates first. It can also pause work because a component is suspending. This is why it's important to make sure your effects are called from useEffect or useLayoutEffect.

Here is a CodeSandbox example of a delayed update. Notice how we're thanking Reactive (see console) before they resolve the ticket. Uh oh.

In fact, Reactive may never process your submitted ticket. Why would they do such a thing?!

Rendered components may never mount

While you are waiting for your ticket to be resolved, you decide to cancel your ticket. The ticket is no longer needed. In React, this is possible when a new update no longer renders your component. A component that is rendered may never show up on the screen! This is why it's dangerous to have side effects in a class component's constructor or render. React may throw away the component and you're left with phantom subscriptions.

Here is a CodeSandbox example where a rendered component is never shown in the DOM. Notice that <MySupportTicket> never shows up on the screen even though it is rendered.

A value logger

Let's put these principles into practice. We want to build a component that console.logs the most recently rendered prop once a second.

// INCORRECT
function ValueLogger({value}) {
  // We use a ref here so we can modify the value inside the interval closure
  const lastValue = useRef(value);
  lastValue.current = value;
  useEffect(() => {
    const interval = setInterval(() => console.log(lastValue.current), 1000);
    return () => clearInterval(interval);
  }, []);
  return <div>{value}</div>;
}

Can you identify the incorrect line?

With Concurrent mode, we can't have side effects in render. They need to be run from useEffect or useLayoutEffect. This includes updating refs.

function ValueLogger({value}) {
  const lastValue = useRef(value);
  useEffect(() => {
    // React will run this after the DOM shows this update.
    lastValue.current = value;
  });
  useEffect(() => {
    const interval = setInterval(() => console.log(lastValue.current), 1000);
    return () => clearInterval(interval);
  }, []);
  return <div>{value}</div>;
}

Without this fix, we may log a value that was never rendered. Using React's git analogy, the component could have been rendered on a branch and was not ready for master.

Hopefully, the customer support analogy helps illustrate how React may decide to delay or throw away render updates. This analogy doesn't hold up all the way. React is not as fickle as a customer support team. Its behavior is predictable. It is just open source code after all.

By guaranteeing render does not have side effects, React gains the power of concurrent mode.