Vue.js and the doubts of considering a new framework
After a year of using Angular 2, Rever decided to rewrite their web client using Vue.js. Was it a good call? In this article, Luis Elizondo weighs in on the struggle of considering a new framework and reveals what happened after the decision was made.
I work at Rever, where we show companies a better way to do Kaizen through a mobile and web application. Our web client was written in Angular 2 using Typescript and after a year of using it, we decided to rewrite it using Vue.js.
One of the hardest parts of rewriting an application in a new framework is the uncertainty of embracing a project that will take weeks while not knowing if you will hit a wall on the sixth week of development that forces you to go back to the beginning. Sometimes, companies cannot afford this risk and they decide not to migrate or rewrite an application until it’s too late.
Finding experiences on successful migrations, and the decision making process before the migration is something you don’t find it plenty on the web, but it can be one of the most useful pieces of information you can gather to finally commit to a new framework. Our doubts were reduced to a very simple list:
- Not reducing the time of development for new features
- Not finding talent
- Ending up with spaghetti code
- Making a wrong architecture decision and not be able to fix it fast
- Not finding third party libraries compatible with Vue.js, documentation or support
- Having performance issues
- Not incrementing our happiness with the finished result
So we started rewriting the application after spending many days researching our list to minimize our risks. After we finished, we started to code improvements and new features and we never felt that development was slow or complicated so we quickly crossed that doubt from our list.
Finding talent with Vue.js experience is an issue we knew we could face; the local community is not as big as others but we also found that a regular web developer can easily pick up the framework and start contributing to the project in a matter of hours.
I have the philosophy that code can always be better, but we haven’t produced a single file with spaghetti code. After the first release we found out that we made a few architecture decisions that were not optimal, but we quickly fixed them in a matter of hours. Lack of experience on a framework is the major cause for architecture mistakes but we haven’t had any serious consequence.
Documentation and support were both easily available, there are plenty of questions answered on StackOverflow and Vue.js documentation is really good. Vue components are available for every major third-party library but when we wanted to add some charts to the project we weren’t satisfied with the quality of the Vue components for the library we wanted to use. We ended up writing our own Vue component abstracting the JS Library and it only took us a few hours to write.
Performance was an issue at first because we use lots of static images but we quickly fixed this and performance improved. Since then, we haven’t had a case where we felt that the performance was not good enough.
12 years ago, when web development was problematic, jQuery released its first version with a very clear goal in mind, simplify the client-side scripting of HTML and web development changed forever. With Vue.js, I feel the exact same way, web development is easy, enjoyable and I feel we have the tools necessary to keep improving our application. I feel excited like the first time I started using jQuery 11 years ago.