Javascript land is an interesting place to be at the moment. New tools and frameworks emerge every day. While jQuery used to rock the boat, developers have moved on to other frameworks to support larger applications more easily.

Over time, we have learned from painful experience how important long term support is for any serious commercial project. However, let me first sketch the landscape…

At inventid we also have a number of Javascript frontend applications running. Some of these (the newer ones) are run on React, whereas others (let’s call these “the older ones”) have been built using Backbone. Since we were using Ruby on Rails for our backends, and were using the asset pipeline from Rails4, we decided to employ Coffeescript as well. This was then compiled to Javascript to be served to the browser. As these decisions were made in 2013, no ES6 was available, so Coffeescript seemed like a valuable tool.

Next step was the decision for a templating engine. As we wanted to have something really lightweight (since it would really impact loading times for end-users which is critical for our conversion), we opted to use Rivets.

Hence we started developing using the Rails asset pipeline, Coffeescript for all client code, and Rivets as a templating language. Sounds easy! And at first it was.

Rivets

Fast forward some years, and we ran into some problems for some projects. The first was the usage of Rivets. Sometimes some interactivity needed to be performed on a dynamic list, we ran into concurrency issues of the framework, so callbacks after clicks could not be properly executed. It turned out that rv-each was completely unusable for these use cases.

Our solution: create collection views and list item classes. It looked like this:

Boilerplate much? YES! Now imagine any serious application and you get an awful number of these boilerplate classes throughout your codebase. Even worse, since these are really specific to a specific place of the code, they are not reusable at all.

We tried to get in touch with the people behind Rivets, but it was determined this was out of scope. Bummer.

As we are developers for a commercial product we prefer working production code over hundreds of hours refactoring working code, we opted for the approach I highlighted above. Not really happy with it, but sometimes shipping stuff just takes precedence over my personal style favourites.

Another issue which occurs often with Rivets (which any developer working with it probably knows) is that sometimes a template will just render as an empty white page. Generally this means there was a syntactical error somewhere, but you never get a clue why. Due to our setup, it could also mean there was a Javascript execution error. So all in all, not fun to debug at all.

Even worse, Rivets could not listen to changes in method return values. So in order to make an element really dependent on a method result, we would need to list every single item which was checked by that method in our HTML. Separation of concerns anyone?

Let’s cut to the chase, in the end it looked like this.

Note the enormous list after the < in the template! Worse still, Rivets was unable to listen to collection changes… So in the end we just implemented an uglyHack variable which we would increment by one every time the collection changed. That would force a recalculation of the method and update the UI. Not all code is created equal ;)

Once you reach that point, you should have realised you are doing something quite bad: Fighting the framework which supports your work. At that point you generally either want to help the framework to change, or change frameworks.

Again we reached out to the developer of Rivets, Googled our asses off, and just tried everything we could think off. We didn’t get it to work any better.

What we hated from Rivets

Most of this all boiled down to one single observation: Rivets was not designed nor maintained by any organisation with a long-term commitment to the project. As a result, there was just a small community. Which in turn results in little usage.

Vue.js

As most readers will know, Vue.js is another Javascript UI library. With some small test app building I loved some of its concepts, and for a personal toy project, I would therefore recommend it.

However it is not backed by some large organization, but mostly a single developer is responsible. And that bring us to the following:

RED FLAG, RED FLAG!

Even though Vue.js is backed by more people and organizations, a long-term buy-in seems absent from the project.

What happens if the developer gets tired of the project? Is the tooling used daily by that many developers such that somebody will focus completely on the developer experience? What is the roadmap for the project?

Most importantly, since incorporating Vue.js in your project, you are committing the the project for your entire frontend for its lifetime (or a very, very long rewrite). Do you dare to take that risk?

React

We already made that error once. And no, we do not want to take that risk again. We have encountered the problems, spend hours getting around the framework, and are stil stuck with it.

In order to move forward, we ditched the Rails asset pipeline, Coffeescript, and Rivets from our new projects and moved to React. Since Facebook is actively using the framework for its flagship products, we can safely expect it to support React for a long time.

Additionally we get other benefits:

React error reporting in development is an actual breeze. The APIs remain really consistent throughout releases (try comparing that to each Angular 1.x release!). If an API changes, usually codemods are available. Building mobile apps became a breeze (we actually moved all of our mobile apps to React native already).

TLDR;

I really believe that React is the safer bet when comparing Vue.js to React (or Angular for that matter*). Is safer always the best way to go? Probably not, but when you buy-in to a UI framework, you better want to be damn sure you can still properly work with it in a few years time.

It seems React will fulfil that promise by balancing speed of development (of the framework) with a proper long-term commitment for your own application. And for once in a while in JS-land, that is a nice place to be!

*) Since Google hardly uses Angular itself, and version 1 and 2 are so different, I do not consider it a serious alternative