Why and How We Migrated from AngularJS to VueJS
- As I’m writing this, we’ve just removed the last line of AngularJS code from our application codebase, ending a 4-month non-intrusive effort to migrate our application from AngularJS to VueJS.
- Then, we have a lot of AngularJS services defined as: – – We simply change them to using ES6 class: – – If there’s still Angular code in other controllers using these services, we clone the services to using ES6 Class, and keep the old Angular copy until no other…
- With the above Vue’s Single File Component, we then change our Rails view file to: – – And then put a code to mount it to the correct Vue component when the page loads: – – In practice, the above JS code is abstracted into reusable function to be called…
- In fact we didn’t really put the migration at our top priority, whenever we need to make a change that touch old Angular code, we first converted it to Vue, and then make our change.
- After the migration, now we have achieved: – – This is not to say Vue is the best, it simply worked best for our specific case: an Angular-heavy application that hits some limitation due to inherent design nature of Angular, and Vue filled that gap perfectly for us, with a…
Read on our personal experience migrating our Rails application from AngularJS to VueJS.
@VueJsNews: Why and How We Migrated from #AngularJS to #VueJS
As I’m writing this, we’ve just removed the last line of AngularJS code from our application codebase, ending a 4-month non-intrusive effort to migrate our application from AngularJS to VueJS. In this post, I’m going to share our experience going through the process.
Our application (Holistics.io) is a SQL-based Business Intelligence (BI) Platform written with Rails, Sidekiq, PostgreSQL and AngularJS. Our Rails app started in late 2013 as a simple app with jQuery and AngularJS. We used AngularJS mainly for the following features/functionalities:
As our application grew, these are the problems we’re facing with AngularJS:
Before making a decision, we took a hard look at our different options:
We did spend some time looking into Angular 2. And to us, Angular 2 is somehow even more confusing than Angular 1. There are too many new changes (TypeScript), new template syntaxes, etc that we felt didn’t really address our core problems. Furthermore, the migration path from v1 to v2 felt a bit fuzzy to us at the time.
We took a hard look into ReactJS. While we really liked the philosophy and the ecosystem, the biggest thing that struck us is we couldn’t figure out a clear, clean, gradual migration path that doesn’t stop us from supporting new features for 3-4 months.