[Case Study] Why we chose Vue to build our desktop messaging app

This post was written by Chris Smith, a front-end web developer at Amity.

Introduction

Amity Messenger is a private messaging, public groups and mobile communities’ app, currently available on iOS and Android.

In our first few weeks at Amity, as the company’s first web developers, my colleague Daniel Lang (Dan) and I faced the proverbial decision — what Javascript framework should we use to build the desktop version of the app?

Together, we had experience with all the major frameworks. In particular, Dan had worked with Angular 1 on various projects during his previous few years before joining Amity and I had worked with Angular 1 and 2 as well as React and React Native for various industries and projects across the startup space and for larger companies.

Our investigation eventually arrived us at three shortlisted contenders — Vue, Angular and React. Ultimately, for a number of reasons, we decided on Vue. In this article, we reveal why.

We’ll start by outlining what we needed in a Javascript framework for the Amity desktop app and how we conducted our investigation, then we’ll delve into our findings with respect to the three main frameworks we considered — Vue, Angular and React. We’ll close off with a retrospective, three months on, about whether we made the right decision.

For any readers interested, we’ve created a public group in Amity Messenger with a growing number of members (including Dan and I) where we talk all things Vue, Javascript and web projects generally. If you’d like to join the group chat, click this link on mobile — https://get.amity.io/spkM/d4mMEhxFiI. If you have problems with the link, download the Amity Messenger mobile app, go to the Explore tab, and search for “The Decision” to enter.

What we needed in a Javascript framework

On a simple level, we needed what every small startup development team needs. Certainty. Certainty that we wouldn’t adopt the latest Javascript fad only to have its longevity pulled out from under us after a few months. Certainty that the framework we chose had a permanent, rusted-on community to keep it afloat and give us support and guidance when we needed it. And certainty in the performance of the framework, that we could push it to meet the growing requirements of Amity’s product offering and not face any performance hindrances that would limit what the product could and would quickly become.

At the outset, we were skeptical of the frameworks that had big-company backing (like Facebook’s React and Google’s Angular). Despite the obvious licensing doubts and concerns we’d have to contend with, we also kept a bias for finding a framework that had proven its independent durability. We wanted to be confident that whatever framework we settled on could endure by its own momentum and volition and wasn’t a victim to the whim of Facebook or Google’s own best interests.

Finally, we looked for ease of learning and implementation, so we could become productive members of Amity’s all-hands-on-deck startup team as quickly as possible. We knew that for every line of documentation we had to read there was a line of code we couldn’t write, so we were especially eager to settle on a framework that we could both easily adopt.

In light of these requirements (ease of development, performance, community, learning curve and expected longevity), and for the reasons outlined below, we think we made the right decision.

How we conducted the investigation

To get an initial baseline comparison, when I first started at Amity I did a broad brush review of Vue, angular.js, Angular, React, Ember, Knockout, Backbone and Polymer. I compared the pros and cons of each with respect to things like licensing limitations, learning curves, performance, community size and activity, tooling, complexity and flexibility and ultimately settled on the three shortlisted contenders, Vue, Angular and React.

After that initial filtration process was complete, both Dan (back-end) and I (front-end) set to work on building out identical prototypes or proof of concepts of a ‘lite’ version of Amity with each of the three final frameworks. The proof of concepts all had the same limited number of features so we could compare some of the key factors we were looking for to make our final assessment.

Angular

From what we already knew of Angular, we initially figured it would be too large and full-featured for what we needed to achieve for the Amity desktop project, but we prototyped with it nonetheless and settled on a number of pros and cons.

Pros

Beyond the obvious advantage of me already having some experience with Angular, it got a big tick from both of us because of its large associated community and the volume of its libraries. While we were concerned with its size and complexity, we couldn’t help but be impressed with how full-featured the framework was and found it to have a great CLI, with scope to generate new components, services, etc.

Cons

The main downfall we found with Angular was the learning curve associated with the framework being built in Typescript and the official documentation and examples also being in Typescript. We also found Angular to not be as flexible or performant as Vue and React. In particular, when we built the prototype using it we found that Angular wasn’t as performant as Vue and React in terms of pure DOM processing and rendering. We also found it to be larger than both React and Vue and too full-featured for what we would need it for with respect to the Amity desktop project.

React

After my initial review of the 8 leading frameworks, React came out on top. But there were some licensing concerns we wanted to explore further and we couldn’t be sure it was the right fit technically until we stress-tested it with our prototype build.

Pros

The obvious advantage of React is its popularity brought on by the profile of its backer, Facebook. While this turned out to be a double-edged sword that inevitably brought it undone, on the positive side it meant there was a huge community supporting the framework (particularly in our local area, which was comforting) and a large number of libraries available for us to leverage for the Amity desktop project. Added to that, the learning curve was easily overcome, the CLI worked really well for us, there was solid state management in place via redux and it would allow us to easily scale. All in all, we were almost swayed.

Cons

In the end, the overriding concern we had with React was its licensing nuances and some legal oddities that dissuaded us. As we mentioned above, the double edged sword to React being backed by Facebook is they exercised some pretty strict legal/licensing controls that inevitably made our mind up for us (like us never being able to sue Facebook for patent infringement, which, however unlikely, didn’t seem like a prudent agreement to enter). On top of those issues, reliable documentation was hard to find under an avalanche of past documentation, there was a JSX learning curve (at least for us), we found it difficult to choose what libraries to use, and we knew we’d have to write more code due to the manual handling of state.

Vue

Before we built the prototypes, I had earmarked Vue as a top-two contender alongside React.

Pros

Performance and ease of development were far and away the standout advantages of Vue. The simplicity of the framework and its size are undeniable advantages for a two-person startup team that needed to move fast to catch up to the iOS and Android projects, currently available publicly. Beyond that, Dan and my experience with Angular 1 meant the learning curve for Vue was small, we were impressed that its reactivity system allows for automatic DOM redrawing out of the box, we found it to have a decent CLI to scaffold a project, and we knew it could be easily scaled.

Cons

Alongside both Dan and I being newcomers to Vue, the standout disadvantages of it were that it only had one full time developer at the time of our assessment (and the only visible funding backing it was Evan You’s Patreon Page, which caused us to feel uneasy about its longevity, coupled with the relatively small community (specifically, there wasn’t much local traction) and the fact that a significant portion of the GitHub issues were written in a language other than English. We also found the Vue templates to be structured strangely (which we were forced to use because of the compiler) and there were some pitfalls and caveats around its reactivity system and the way data is updated and changed (see here).

Three months on, we have no regrets

In a turn of fate that we didn’t expect, two weeks after we made the decision to go with Vue, Facebook loosened their licensing conditions over React — the same licensing conditions that dissuaded us from adopting it as our framework. Only two sprints into our development with Vue, we faced a conundrum. We were in a position to turn back the ship and jump over to React if we wanted to, and the decision caused us some dismay. Again, we had to weigh up the pros and cons of the two languages in light of React’s licensing condition no longer posing a limitation. But by then we had hands-on experience developing the real app with Vue and we were confident that its advantages (particularly performance and ease) outweighed the advantages of React.

And three months on, we feel satisfied making the decision we did. While the Vue community still isn’t as large as React’s (particularly in our local area), we see it growing daily, and the performance of Vue and its ease of development has allowed us to build out the internal beta of the app much quicker than we first timelined. The Android and iOS teams can feel us breathing down their necks, and we hope to overtake them in the new year and lead Amity’s rapid iteration approach to product development sooner rather than later. A lot of that is thanks to our decision to stick with Vue.

Conclusion

As every software engineer reading this will know, making long-term, project-specific technical decisions like this are unavoidable, but never easy. The good news for us is that the work Dan and I did paid off, the four-week investigation served its purpose, and we’re confident we ultimately made the right decision to use Vue to build the desktop version of the Amity app.

On that note, we look forward to releasing the first publicly available version of the desktop Amity app in the coming months. If you’d like to be on our list of early adopters to trial the app, please email us at desktop@amity.io and we’ll include you in an eventual release mailout. We’d love to include as many software engineers as possible to garner their feedback.

For any readers interested, we’ve created a public group in Amity Messenger with a growing number of members (including Dan and I) where we talk all things Vue, Javascript and web projects generally. If you’d like to join the group chat, click this link on mobile — https://get.amity.io/spkM/d4mMEhxFiI. If you have problems with the link, download the Amity Messenger mobile app, go to the Explore tab, and search for “The Decision” to enter.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.