React and Vue.js – A Comparison of Ecosystems

Most of us are somewhere in the middle, feeling the responsibility we carry. Gathering more information should make the decision easier but the contrary turns out to be true: Often, the more you know about your options the more difficult it becomes to make a decision. And in the end it comes down to the gut.

The view library is the place where most components are written and it should be fast and easy to understand. But especially in larger single-page applications there are other considerations as well.

Embracing the values of the internet you'll want to make use of frontend routing, thus you’ll need a tool for that. As soon as the app grows, you’ll want to rely on state management that is robust and comprehensible. Further, being the exemplary developer you are, you’ll want to make sure that your code is tested well.

Even if you're not looking for a full-service framework, you probably want these tools to integrate well. Two of the most popular view-only libraries around, React and Vue.js, both have rich ecosystems with solutions to all these matters and are good subjects for such a comparison. Let’s look at documentation quality and contribution activity before diving into the more technical aspects.

Community

Let’s start by looking at some numbers. Numbers aren't everything but it is good to have an overview before delving deeper into the specifics.

Since we're not writing apps for internal use but for clients that might rely on long-term support we also need to make sure that the tool of choice will still exist in a couple of years. Many users are obviously a good sign for that. Also, as developers we love to find answers to our questions on Stack Overflow. Since the probability for that grows with the number of topics, more questions are – in this case – a good thing.

##Contribution

Looking at these numbers it seems like Vue is the underdog in this comparison. That might have to do with the big hype that emerged around React in the last years and which led to a massive rush to the library. But it seems the community around Vue has learned from that and is creating a lot of buzz, too. You can see that in dozens of blog posts about Vue popping up.

And it is not only in writing posts that the people around Vue are busy. The documentation is among the best you'll find and they work hard to implement new features into the newly released second version.

But comparing their contribution graphs on GitHub it is clear that React still receives more commits on a monthly basis – and a lot of people make a lot of difference after all.

Documentation Quality

As one would expect both libraries can score with good docs. Every aspect of their respective APIs is explained thoroughly and demonstrated with some examples.

But while the React documentation focuses solely on the library itself, Vue also gives information about topics that aren't covered by the core package. The reason may be that React doesn't officially support or recommend any of the solutions for routing or state management while Vue does and offers a short introduction for each before referring to separate docs.

If you're really into documentation, you'll be happy to dive into Vue, just to be overwhelmed by the massive amount of information in their docs. React gives you all you need to work with it, but doesn't go any further than that.

Dev Tools

Dev tools aren't explicitly a part of a contribution analysis. But providing an inspector is a good indicator of the amount of work contributors are willing to put into a library.

Both libraries came up with their own version of dev tools. I tested the Chrome extensions, so I can't say anything about cross-browser development.

After all the react-devtools seem a bit more mature, showing not only the components but also their connection to the DOM. Jumping between the React and Elements tab of the Chrome Dev Tools goes flawlessly by right-clicking and showing the respective node. Vue has a button for inspecting the DOM but it didn't respond when I clicked on it.

Both Dev Tools provide a search so you can filter the component view. React provides a regex option and allows you to inspect search results of multiple threads so you'll be able to get a deep understanding of the composition.

While Vue has a more tidy interface React offers the option to apply different themes to the tools. No biggie, but when you're looking at these things all day they might as well look nice.

Templating

React is the birthplace of the JSX syntax so it shouldn't surprise you that this is actually the recommended (and best) way to write components with this library. While it might feel strange to newcomers to mix HTML into JavaScript, most frontend developers have adopted this way of writing code. Other frameworks mimic the feature by using the ES2015 template string but in my opinion JSX is much cleaner and easier to read. It needs to get precompiled which makes it impossible to use for some edge-case projects. In larger frontend applications that shouldn't be a problem, though.

You can write JSX in Vue as well, and the template string option is also available. But the recommended way is to use "real" templates with their own DSL (Domain-Specific Language). That means writing syntactically valid HTML elements with extensions like v-for to perform a loop or v-on to attach a listener. That makes it easier to read for anyone who otherwise has hard time reading pure JavaScript but this advantage can disappear in complex and thus cluttered scenarios.

The many options you have when writing Vue components might seem like a good thing but in my opinion it makes development unnecessarily more complex. You'll not only have to design the components but also decide on the way you want to write them. The Vue docs even go as far as recommending a mix of using templates and the render function. In larger projects this can lead to an inconsistent codebase or problems to find a solution that fits to your chosen way of writing components.

React components on the other hand breathe JSX. While the syntax – especially some changes to HTML attributes – might take some time to adjust it feels more consistent and flexible, without offering too many ways of writing and organizing your code.

State Management

If your application gets just a bit bigger than a Todo-List you can't (and shouldn't) avoid implementing some kind of state management tool. When releasing React, Facebook also presented their solution to state – Flux. Flux prescribes avoiding two-way in favor of unidirectional data flow.

Nowadays the principles of Flux have been refined by many other libraries. All of them strive to make state management in the frontend reliable, comprehensible and in sync with the backend and most of them also work without a specific view library.

For most React applications Redux has become the de-facto standard, both for smaller and bigger projects. Since Redux is unbiased towards the rest of your technology you can also use it in combination with Vue. However, the Vue docs recommend using their own Flux implementation called Vuex – which has its own section in the Vue Dev Tools.

To make a full comparison of Redux and Vuex would definitely be too much in this context. But state management is an essential part of developing frontend applications and the two solutions are each closely related to the respective view libraries. So, let me give you at least some brief information.

First of all, both tools do a good job at their core and both of them have great dev tools that make the development process amazingly smooth. You can navigate through the state history, watch as the actions/mutations take place and thus find bugs early on. The Redux tools provide some more features like pinning your state, so it stays the same after reloading the page.

In regards of development I see the biggest difference in the immutability of state. Embracing principles of functional programming, Redux doesn't allow you to modify the state directly. Instead you will create a new state while applying the changes made and returning it which requires the responsible reducer and all actions to be pure functions. This makes the code robust and easy to test.

Vuex on the other hand relies on mutability. That means impure functions, modifying the state as a side effect. In a test project this forced me to overwrite the state parameter inside the function, which – not only for most linters – is an absolute no-go.

Routing

It seems that in all frontend frameworks – apart from Ember – routing is seen more as an additional feature than as part of the core product. The reason for that might be that frontend routing can be complicated. It has to closely work together with the browser and respond directly to user events. It has to deliver information about the state of the app in form of only a url and prevent traditional links to reload the page.

A lot of responsibility for a feature. But routing is also located at the heart of the internet's ideals. To share resources with each other people have to be able to point to them. If the routing is broken, the information might be lost forever.

Both view libraries have a preferred routing solution in their respective ecosystem: the react-router and the vue-router. Both work properly and integrate well with the view. That is, until you bring state management into the mix. The single source of truth, as it is defined in the theory of Flux, should be the store – may it be Vuex or Redux.

The router creates a theoretical and practical problem for state management because it provides an additional source of truth. Implemented as additional package in both libraries it only solves its own problem without regarding the rest of the app. Fact is: As soon as your app grows large you see that the decoupled routing state is cluttering your code and thereby reducing the maintainability of the product. Both routing solutions suffer in this regard.

On the React side, though, promising efforts regarding these issues are made. Redux-first-router combines the principles of Redux with routing. I've given it a go and it does a great job by not being in the way and being accessible through the regular state flow.

I think the Vue and Vuex community will need to come up with something similar before they can compete with React in this area.

Testing

When it comes to testing, Facebook – with its comparably unfair amount of resources – is one step ahead of the Vue community since they released their own testing framework Jest. It integrates well with React – naturally – and removes the need to look for additional libraries and packages by including almost everything you need.

After spending some time with Jest, I can say that it really takes a lot of hassle out of frontend testing and might even encourage more frontend developers to start testing their code – but I may be too optimistic here.

Vue on the other hand also has a recommended way of testing apps by suggesting Karma configurations for Webpack and Browserify. For more complex things like mocking or showing code coverage you'll need to look for additional dependencies.

It should be possible to use Jest also for Vue apps but depending on the way you write templates you could run into some preprocessing problems. I didn't find a lot of guides explaining Jest's integration into a bigger Vue project, so that would require some trial and error but might be worth trying out.

Reuse of Knowledge – Native Apps

When building native apps for platforms like Android or Windows in the past, you were typically forced to hire specialists for every major OS you wanted to support. But today, big Start-ups like Slack started with JavaScript as their main language with allows them to build both native and web apps based on the same codebase. Needless to say that this can be a huge advantage. But what if you also want to reuse the framework you’re building on?

React Native provides a good option for developing mobile apps with the knowledge of frontend developers. While utilizing the features and functionality of the native device, React Native is written like a regular React app – in JavaScript.

Vue currently doesn't have this kind of cross-platform opportunity but a framework called Weex is under development of the Chinese E-Commerce company Alibaba. It is still in a very early stage but might be an alternative in a year or two.

Server-Side Rendering

While some projects can live without pre-rendered markup from the server, this feature should always be considered. It doesn't only serve SEO, but more importantly, the performance of the app. New, high-end mobile phones aren't the standard everywhere and most users have to rely on a slow internet connection. Delivering content ready for consumption from the server immediately can make a huge difference in these cases.

React started a movement towards isomorphic rendering by providing a model for its usage both on client and server shortly after its initial release. Now giants like Netflix and Paypal use server-side rendering in their products which indicates how stable this technology is.

Vue, due to the small size of the team, took its time to jump on the server-side train, but included it in the release of the second major version at the end of 2016. Now, as with all Vue-related packages, you can read through a vast amount of docs about it.

Routing and state management are the most common issues when implementing server-side rendering and here the relatively small size of the Vue community becomes noticeable once again. With not as much backing as the React ecosystem has, users might have a hard time implementing Vuex for isomorphic rendering due to the lack of resources. Redux, being more mature and popular, dedicated an own "recipe" to the topic and you'll quickly find blog posts and tutorials about it.

Summary

Looking at the numbers one might think that the decision between React and Vue isn't even worth considering as the Vue community can't possible compete with the amount of work Facebook can put into its most famous library. Thanks to a massive marketing campaign, the community around React is, though just one year ahead, a lot bigger – to the profits of its ecosystem.

Nonetheless, Vue is definitely worth a closer look. Learning from the biggest players they managed to make a lot of things good and some of them even better than renowned competitors. The impressive documentations around every Vue-related library or tool is outstanding and compensates the few resources on other pages like Stack Overflow. Being independent from any big company also gives a sympathy bonus.

Taking the good parts of other libraries is a good approach but it has the downside of always being one step behind. Not being able to tackle many issues at once means a lack of technology that the competition already has – the redux-first-router is a good example for that. And while you can be sure that the hardworking Vue contributors will eventually come up with their own solution, you might need to wait for it a bit longer.

For the usage in most applications and the tiny bit of interactivity in static websites Vue is definitely worth looking into. In these cases it probably comes down to personal preferences and experience. But as soon as your project grows big or you face the one special case that is nowhere to be found in the docs, React's mature ecosystem and its many experienced users might make development a lot easier for you.