Insights

5 reasons to consider Vue.js if you’re a large organization

Front End Director Andres Zorro gives his five reasons as to why you should use Vue.js…

I know, I know. This article might look like yet another **Vue.js vs ******. If there’s one thing Front End developers love – besides writing JavaScript frameworks – it’s writing articles comparing JavaScript frameworks and defending the opinions behind it. There are some really good ones, like this one, or this one. (By the way, if you’re not into web development or you run a web application and you still don’t know what Vue is, read this one first).

I want to weigh in my personal opinion as a technology manager who has witnessed how Vue has helped large organizations into modernizing their products, in ways that I have never seen before with other technologies. Typically, this kind of post would continue along the lines of,“here are some reasons to use Vue in your next project.” But often times, large organizations don’t have a “next project”. They have large established products, with revenue and customers and KPIs. They know their tech is old and they want to revamp it. But the cost of doing it is so high that there’s little chance that a full refactor might be approved. Even the word refactor is feared amongst product owners. But what if I told you that refactor is not only possible, but highly maintainable and even fun, thanks to Vue?

But first, before even thinking about refactor, a word of wisdom: have a proper automated End-to-End (E2E) test framework in front of your application, at least for the critical paths. No refactor can be done properly without making sure your application will keep working the same after the switch. You have been warned.

So, here are five reasons to switch to Vue.js in your current products:

1. Entry cost is really low

A Vue template file resembles a standard html file. It has three main tags and content in it: A

Vue is also very lightweight. Even lighter than jQuery! So adding the script on top of your other dependencies is a tolerable overhead, considering that eventually you will remove others.

2. Hiring two developers for the price of one

Let’s be honest. Teaching Angular’s Reactive Programming and dependency injection concepts to a seasoned React developer, or teaching Higher Order Components and function composition to an Angular developer, is an overhead nobody likes to have in a product on a deadline. People might have opinions and it might be hard to convince them to go one way or the other. And even if you are able to align your entire team to a single paradigm, there’s a chance that a new hire might open this can of worms over and over again. Considering that Vue has multiple patterns that draws inspiration from frameworks that preceded it, I see Vue as this middle ground in which all Front End developers from different backgrounds converge. Even developers who have no previous experience with frameworks!

It’s also worth mentioning the amazing documentation that the Vue team and the community have put together. Guides to getting started are simple to follow and core concepts are thoroughly explained. So you can feel relieved about looking for new hires with background in either React or Angular; I’m sure they can pick up Vue in no time.

3. Start from the leaves, not from the root

Large organizations struggle a lot when defining a common visual language for their products. Typically, different teams start off their products in parallel. With a lot of good intentions, several development teams try their best to write reusable widgets with the goal for them to be distributed across the company. The problem is that some products may have started in Angular, while others in Ember and React. Maybe those products did not start at the same time and their versions are locked down for any compliance reason. So the library of widgets written in Ember 1.18 does not play nice with the Angular 2 container application. And the company ends up with four implementations of the same carousel widget. A lot of rework, isn’t it?

Well, Vue has you covered. Given the light footprint of the library file, it’s easy just to drop in the dependency and render the widget. Vue’s API plays nice with other libraries, and depending on the level of complexity your implementation might have, you can even ship web components compliant with the W3C spec, including the Vue library itself, in a tiny packaged dependency. No more searches for “nested ng-apps” in StackOverflow. Vue plays nice even with different versions of itself!

When you are done creating components and widgets, and you have composed entire pages out of your Vue widget library, Vue can also help you refactor some of the more critical areas, with packages that are officially supported by the same maintainers of Vue: vue-router, vuex (for state management), vue-cli (for scaffolding) or Vue SSR (for rendering). Moreover, if you feel like investing in server side rendering with Node.js, there are libraries like Nuxt, which, even though it’s not officially supported by Vue team, has the same top notch documentation standards.

4. Designed for developers, by developers

An indicator of good health in open source projects is the “GitHub stars rating”. It is not comparable to the usage in production metric, but it speaks of the influence and support of the community. Many non-Vue adopters usually speak against Vue for many stylistic reasons, and those are the more opinionated (usually senior) developers. But the fact that Vue surpassed React in GitHub stars at one point, is a good indicator of adoption amongst mid level to senior developers. At Zemoga, we have some Vue “evangelists” and even when we consider ourselves framework agnostic, for our internal projects the framework of choice has always been Vue and the developer experience could not be smoother.

Vue is the only major framework that is not backed up by any major tech giant (Angular is backed by Google and React by Facebook). Historically, this has been an argument against the adoption of Vue, but I actually consider that fact its real strength. While other frameworks started off by solving internal product requirements and were then released as open source, Vue started off by solving the developer experience in the frameworks available at that time. So this focus on the developer makes Vue really enjoyable, and I strongly believe that a happy developer is a productive one.

5. Built to last

With changes in evergreen browsers, JavaScript engines, ECMAScript specifications, frameworks and tooling happening at the same time, it’s really hard to keep everything backwards compatible and get the benefits of the new features without compromising performance and API integrity. The classical example is Angular 1.x to Angular 2. But after that episode, things have changed and major JavaScript frameworks learned the lesson. And Vue takes compatibility very seriously. According to the roadmap and plans for Vue 3.0, and considering that they will have breaking changes, most of the base API will remain the same, or will have a compatibility build as well as other paths to upgrade from previous versions. This commitment shows the framework’s maturity and stability looking into the future.

So, what say you?

Switching to a new technology is sometimes scary, and even more so when it comes to large organizations. This article is just my personal opinion, but companies such as Netflix, Alibaba and GitLab are already using this framework in their production environments.

At Zemoga, we are invested in creating a balance between user experience and technology. We are adopting principles of atomic design and working our way towards Component Driven Development as a best practice. Vue is one of these technologies that helps us in adopting such principles in a way that is effective, sustainable and enjoyable. And while it is not the only one – like I said, we are technology agnostic – we are confident that technologies that bring our teams together are worth investing in. We are ready to build better together. When shall we start?

Andres Zorro has been a team member of Zemoga since 2013 and is currently their Front End Director. He also runs his own blog at medium.com/@zorrodg.

About the author

Andrés Zorro is a Principal Architect with a Front-End background. He has over twelve years of experience developing and executing end to end solutions, and has helped guide teams by sharing his findings across multiple countries and timezones during this time.