Vue vs React — Part 0: Thinning the Herd

Joe Podwys
Dec 21, 2018 · 5 min read

In this series, I demonstrate some of the key development experience differences between using Vue and React to achieve the same outcomes.

Image for post
Image for post

Table of Contents

Part 1: By the Numbers

Part 2: Basic Components

Part 3: Advanced Components

Part 4: Advanced State Management with Vuex and React-Redux

Part 5: Decision Time

I was recently tasked with selecting a front end component library for the future of our product at work. I started with a list of options and quickly filtered it down to Vue and React.

Angular — Learning Curve

Examples of additional complexity exist in app architecture, component definitions, and even template bindings. Perhaps one of the largest hangups for people not already familiar with it is Angular’s use of dependency injection.

Dependency Injection

The primary benefit of dependency injection is ease of testing — because you have control over what dependencies gets injected into your modules, you can easily pass mocks when testing. While admittedly valuable, this added convenience in testing comes at the cost of readable code. Under this model, components rely on dependencies they did not import provided to them by an extra layer of application logic. Requiring devs to embrace this design pattern in order to be productive is one of the things that makes Angular’ hard.

What if we could have the best of both worlds? What if we could write our components the industry-standard way where each component imports its own dependencies while also enjoying the testing benefits of dependency injection? Fortunately, Jest has us covered! Jest provides a means of intercepting import and require statements and swapping them with mocks. It’s dependency injection that doesn’t require you to write your code differently. Here are a couple of demos.


Due to concerns about download size, several issues with learning curve, and not wanting to go all in with a framework built around dependency injection, I opted to forego Angular.

Svelte and Stencil — To Soon

You can’t write serious applications in vanilla JavaScript without hitting a complexity wall. But a compiler can do it for you. — Svelte Blog

Here’s the idea. You write your code in a clean, readable way, and Svelte/Stencil compiles it into something tiny, fast, and vanilla. Seriously, you can use these components with any framework or library. And it works extremely well! It takes the runtime you normally have to download and abstracts it away into a build step.

So what’s wrong with Svelte? One of the major considerations when taking a for-profit business into production is community. Are there pre-existing components? Are there docs? How big is the team that supports it? Will I be able to hire people who know it? Asking these questions helps you avoid risk.

The answers to most of these questions are not favorable enough to write an entire application using Svelte. A tiny example: Svelte doesn’t have its own router and doesn’t have a good virtual scroll implementation. Yes, I’m aware there are excellent off-the-shelf options such as PageJS and Navigo. But this at least demonstrates, on a small scale, that there isn’t a reliable first-party-maintained solution for some of the fundamental app building blocks out there — fundamental building blocks for which most ecosystems have first-party solutions.

The same issues apply to Stencil — it’s just not mature enough yet.

Now, ruling out using Svelte/Stencil for an entire application doesn’t mean we’ll rule them out for writing some of our individual components. In fact, using them for some of our more complex shareable components could insulate us from future change because their output is vanilla JS. Of course, doing so would require my team to learn a second new component library… We’ll cross that bridge when we get there.


Preact — So You’re Telling Me There’s a Chance

Fast 3kB alternative to React with the same modern API. — Preact Docs

I’ve been using Preact in a personal project for over a year and I’ve really enjoyed it. With React still being on the table and Preact being so similar, it makes sense to at least try it out in the event we go with React. Here’s a list of differences between the two.

What’s good about Preact?

  • Preact is one tenth the size of React. This improves bundle size and execution time.
  • It’s API-compliant with React so you can use preact-compat to swap out React for Preact in an existing app and it Just Works™. It also allows you to enjoy React’s entire component library (mostly).
  • Its CLI is great, providing a PWA with route-based code splitting out of the box. What’s more, you can configure its starting template yourself.

What’s bad about Preact?

  • Preact follows React’s feature set. This means that it’s always behind React’s latest release.
  • preact-compat doesn’t always work.
  • Preact’s docs are sparse because they expect you to read React’s docs.


If, by the end of this series, we decide to go with React, I’d like to give Preact a try. Doing so can keep our stack overhead as small as possible while theoretically still granting us access to React’s component ecosystem. And, if it doesn’t work out for whatever reason, the risk is small — converting it to React proper should take very little time.

Continue to Part 1:

Part 1: By the Numbers

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store