Why we chose Vue.js

• 6 min read

Why we chose Vue.js

Choosing the right modern JavaScript framework for a big business was going to be tough, the best way to approach it, is to consider the needs of the business, users, and developer convenience. Let me explain why we chose Vue.js.

Background

My experience of modern JavaScript frameworks before this was limited to personal use, as I'd been happily living in vanilla JavaScript land for a very long time.

My Frontend dev team is new to the business, so the experience they have with frameworks isn't representative of our entire developer population.

The business wants to deliver better products, faster than ever. And here's how we can do that...

Write less code

There's a great blog post by Rich Harris a developer working for the New York Times called Write less code that makes the point that all code is buggy. It stands to reason, therefore, that the more code you have to write the buggier your apps will be.

...all code is buggy. It stands to reason, therefore, that the more code you have to write the buggier your apps will be. - Rich Harris

Writing more code takes more time, and it's acknowledged that project development time and the number of bugs grow quadratically with the size of the codebase.

As developers we often see this in our code review process, a ten-line pull request will get a level of scrutiny rarely applied to a 100-line one.

Our use of a modern javascript framework will benefit the teams using them be making code more easily reusable through the use of single file components, but what about that actual amount of code it takes to get the job done?

A character count comparison between React, Vue, and Svelte by building the same component in each.

React - 442 characters

import React, { useState } from 'react';

export default () => {
  const [a, setA] = useState(1);
  const [b, setB] = useState(2);

  function handleChangeA(event) {
    setA(+event.target.value);
  }

  function handleChangeB(event) {
    setB(+event.target.value);
  }

  return (
    <div>
      <input type="number" value={a} onChange={handleChangeA}/>
      <input type="number" value={b} onChange={handleChangeB}/>

      <p>{a} + {b} = {a + b}</p>
    </div>
  );
};

Vue - 263 characters

<template>
  <div>
    <input type="number" v-model.number="a">
    <input type="number" v-model.number="b">

    <p>{{a}} + {{b}} = {{a + b}}</p>
  </div>
</template>

<script>
  export default {
    data: function() {
      return {
        a: 1,
        b: 2
      };
    }
  };
</script>

Svelte - 145 characters

<script>
  let a = 1;
  let b = 2;
</script>

<input type="number" bind:value={a}>
<input type="number" bind:value={b}>

<p>{a} + {b} = {a + b}</p>

Evan You, creator of Vue, also performed a similar exercise. Here's a side by side comparison of how a similarly simple component looks in Vue, React and Svelte. Although, full disclosure, he's also demonstrating the new composition API here.

Evan You Framework tradeoff comparison

Who wouldn't want to write less code and get more done!? Maybe I'm a lazy dev, but from a business perspective less code to maintain is a big win.

Learning curve

With modern JavaScript frameworks being new to many of the developers in the business it's critical that we're not forcing SQL gurus, and C# boffins to pick up the most difficult tool in the box.

In React, all components express their UI within render functions using JSX, a declarative XML-like syntax that works within JavaScript. Vue also has render functions and supports JSX, because sometimes you need that power.

However, the default experience with both Vue and Svelte uses templates as a simpler alternative. Any valid HTML is also a valid Vue template, and this leads to a few advantages of its own:

  • For many developers who have been working with HTML, templates feel more natural to read and write. The preference itself can be somewhat subjective, but if it makes the developer more productive then the benefit is clear.
  • HTML based templates make it much easier to migrate existing applications to take advantage of reactivity features.
  • It also makes it much easier for designers and less experienced developers to read and contribute to the codebase.

Getting production ready

You're probably thinking that I've made a strong argument for Svelte so far, so why did we choose Vue? Well I have a lot of love for Svelte, however there are a few things holding it back for use in customer facing products.

The ecosystem

All three of these frameworks are single page applications, which rely 100% on JavaScript for rendering pages. So what's wrong with that? Well it's not SEO friendly for a start. "But Google indexes sites using JavaScript now Ben". Well, yes and no, there are two indexing passes performed by Google, the first deeper crawl is performed without JavaScript support and a second about a week after the first with JavaScript support. And let's not forget that even though Google have the monopoly, other search engines like Bing, and DuckDuckGo don't support JavaScript only sites.

To make sure our content gets found and indexed by search engines it has to be delivered using server side, static, or universal rendering.

To make sure our content gets found and indexed by search engines it has to be delivered using server side, static, or universal rendering.

Server side rendering

Everything is done server side, including route transitions, the original and most fundamental pattern on the web.

Static rendering

The initial view and content are rendered as static files server side, then the app is "hydrated" at the client side to make it interactive and behave from that point like a traditional single page application.

Universal rendering

The initial view and content are rendered server side, then the app is "hydrated" at the client side to make it interactive and behave from that point like a traditional single page application. Some functions are still handled by the server and don't need to live in the app framework.

So this is where Svelte falls short, its current ecosystem lets it down, at least right now. None of these frameworks support full server side rendering, but that's by design. Here's list of tools to help us use these frameworks with static or universal rendering. All data correct at the time of writing.

React frameworks

Vue frameworks

Svelte frameworks

Sveltes ecosystem is in it's infancy, so being pragmatic with our approach means we should go with frameworks that are battle hardened. That crosses Svelte off the list, as least for now, I'm incredibly excited to see Sapper get to a v1 release.

Summary

So with Vue sitting in the middle of the road when it comes to code character count, an easier to pick up syntax that uses standard HTML, and a healthy framework eco system to back it up. It's the clear choice for building production ready SEO friendly applications, that will be approachable for developers new to modern JavaScript Frameworks.

Oh and, we're not the only company coming to the same conclusion. Nasa, Adobe, Sainsburys, Alibaba, GitLab, Baidu, Grammarly, Netflix, EuroNews, Laracasts, Behance, even Facebook (creators of React) are just some of the companies using Vue in some capacity! Here's an official list of companies using Vue

Companies using Vue