Why we choose Vuejs which is not React or Angular
- 2018-11-26 12:14 AM
At Rever we just released a new version of our web client using Vue.js. After 641 commits and 16 weeks of intense development here we are, very proud of a decision we took a while ago.
At Rever (www.reverscore.com) we just released a new version of our web client using Vue.js. After 641 commits and 16 weeks of intense development here we are, very proud of a decision we took a while ago.
8 months ago our web client was using Angular 2. To be precise, it was using Angular 2 beta 9. This was a product written by an outsourcing company and we were never fully happy with it on many levels, from UX/UI to the architecture, and to some level, with Angular 2 itself.
Before I continue, I admit that Angular 2 beta 9 is a different product than Angular 2.0, but that was exactly one of the problems. From beta9 to 2.0.0 there are 8 beta versions, 8 RC and the 2.0.0 version itself, 17 versions to upgrade in total. We did try to upgrade from beta 9 to 2.0.0 but too many things broke that made the upgrade non trivial. Also, about the same time we were questioning Angular 2 as our framework of choice, the Angular team decided to start working on Angular 4. While they promised it wouldn’t be too drastic, that meant that by the time we finished upgrading to Angular 2.0.0 we were going to need another upgrade. What a waste of time and limited resources.
I still remember how easy to work with Angular 1 was, it certainly had its own problems, but it was nice to work with it compared to other frameworks, something that Angular 2 lost somewhere on the way. My conclusion about Angular 2 was simple**, the only thing Angular 1 and 2 share in common is the name, they are completely different frameworks.**
So consider that we had 17 versions to upgrade on a non-tested system, a lot of pressure from the business to write new features, lots of bugs and poorly written code, the original developers weren’t on the team anymore, only one developer (me) at the time with many other responsibilities, Typescript, problems with finding the right documentation since I was using a beta, and Angular 2 moving to version 4. The list of negatives started to accumulate very rapidly.
We made a decision, if we were going to spend that much time upgrading, we needed to see if we had other options first. And we did.
The first obvious choice was react, because well, everybody is doing it and the ones who are not, are talking about it. So that was one option, certainly knowing that Facebook is behind it, helps. However, React itself is not a framework, you need to add extra stuff to make it shine.
Vue.js was a new player, I never heard about it before although they just released version 2 back when we started to look at different options. At first it caught our attention, but it looked risky.
We first started to define what our decision points were going to be. We knew the framework of our dreams would need to have the following:
- It should be stable
- Backed by a strong community or some big players
- Good documentation or lots of questions on StackOverflow
- Easy to learn
- Integration with Bootstrap
- Small size
- Ideally it would allow us to reuse code
- Coding speed test should be increased
- Component based
After having our decision points decided, I had to get my hands dirty, so I gave both React and Vue.js a couple of days each to review each decision point that wasn’t going to be answered by Google. Since I knew nothing about any of them, at the end of two days I would reevaluate how far I got into rewriting some parts of the actual project we were going to migrate.
The parts I chose to rewrite were:
- Some basic API calls
- Two layouts for two different pages.
- Reactivity for user related stuff
- Login Forms and some content forms
- One bootstrap modal
I was surprised by how far I got with Vue.js, in a couple of days I actually had a proof of concept to show up to the rest of the team and to my CTO. I got a good understanding of the basic concepts of Vue.js, defined a good and extendable architecture but most importantly I really enjoyed the experience of writing code with it and I felt I was doing it faster than with React.
React was a lot harder than I thought, choosing between Redux and MobX is more problematic than having one option that is well integrated with the framework like Vue.js and Vuex do. This is simple because when having no experience with a framework, it gives you more confidence knowing than a framework has an official library for doing something. By the way, I felt that reactivity was easier with Vuex than with Redux but probably that’s just a perception, like all learning curves.
JSX was also a problem since we could not reuse HTML code and Vue.js did allow us to do it to some extent. Vue files are actually pretty good to work with since I don’t like inline templates. React mixes both JSX/HTML with JS code which I just don’t like since I strongly believe in separation of concerns and it looks ugly IMHO.
Coding speed was an area Vue.js won by far, not having to learn JSX was of huge help. This speed was later confirmed when another developer joined the project and was contributing to the project in a matter of hours after a training session of about 1 hour.
To have proper speed we needed good documentation and Vue.js documentation is superb. Guides, examples, questions and API are documented really well and cover all of the doubts we found during development. We were afraid to find Chinese documentation for many of the questions we would had but that was not the case, everything was available in English.
Vue.js looked really good after more than a week of consideration but to my surprise, asking around was useless, since no one had used Vue.js before, the only comment I got was in the order of “looks cool but I haven’t used it”. React took the most mentions and Angular 2 came in a distant second place.
I started to look for local talent with Vue.js experience and I did find some who were really good so I started to think that I was not alone, my social techy circle was probably too small and I shouldn’t play enough attention to the fact that I didn’t know anyone in person working with Vue.js on production.
At the time we were thinking about Vue.js vs React, we were also considering rewriting our mobile app and React Native looked like a really good choice. That was a big plus for React since Vue.js didn’t have anything remotely stable that resembles what React Native is trying to do, so the possibility of reusing code between the web and app clients was a huge plus, but I decided that I wasn’t going to consider possibilities that might or might not happen. After all, from my experience, with Node.js I reuse a really insignificant amount of code between the browser and the server.
At the time I write this, there is great amount of discussion because Facebook changed the React license to BSD+Patents. According to Facebook, this license is meant to protect them from patent trolls. This was not primordial in our decision making process but I’m glad we didn’t go the React way since any noise related to Licenses is not a noise you want to hear.
In the end, Facebook being behind React might become a liability for the project instead of a strength, that is why it is usually better to have independent foundations or organizations in charge of a successful Open Source Software project. Facebook should do the right thing, take IBM as an example, when IBM bought Strongloop, they donated Express.js to the Node.js foundation where such an important software belongs. Pressure from the community and willingness from IBM to ensure the continuity of the software made it happen. Twitter is another good example, they released Bootstrap under the very permissive MIT License and no one is talking about License problems with Bootstrap.
Overall, Vue.js was the the winner in our evaluation, it had many questions answered on Stack Overflow, the clearest official documentation of the three options, the smallest code base, integrates well with Bootstrap and learning that it was backed by strong projects like Laravel and a big company like Alibaba was a big plus. Not having a community as big as React’s was not a real factor since it was big enough.
Going with Vue.js was the right choice, it took me a while to convince my CTO but I’m grateful he always asked the right and tough questions and force me to be 100% sure of my decision, I was going to regret it if I made a mistake. I think there was a small part of him that wasn’t sure until he wrote a whole component and found it really easy.
In the end the whole decision process was really helpful, but the fact that I was able to learn really fast made a huge difference, call it gut feeling if you like, but learning something really fast gave me great confidence in the more complex problems that I knew I would face during actual development.
I’m not saying React is a bad choice, I’m surprised by how big the community is and there’s a good reason for it, but jQuery is bigger and that doesn’t make it a good framework / library for the project we wanted to do.
Vue.js is gaining momentum and we saw that during development which only reassured us that we took the right choice.
We value simplicity and Vue.js achieves that, this simplicity is reflected on the learning curve, the documentation and specially in coding speed. If you’re still confused or need more arguments, I encourage you to go and read the following link:
Rever (www.reverscore.com) is an online platform that enables companies to engage all their employees in frontline innovation every day. Rever demystifies innovation and makes it a daily habit for everyone. We are always recruiting, if you want to work with an amazing tech team, check out our opportunities at https://reverscore.com/careers/
Luis Elizondo is the Lead Engineer at Rever where he does Backend and Frontend Web development. He’s also in charge of automation, infrastructure, systems architecture and security. He has more than 10 years of experience working with multiple programming languages, designing application architectures, automating processes and operations and administering servers on the cloud.