Since launching Cushion a couple years ago, we’ve been using AngularJS (1.x) as our front-end framework. If you’re curious how we ended up with Angular, I wrote about the decision (keep in mind this was 2014). I came from an MVCS background, so Angular really resonated with me, and it has served us well this entire time. Recently, however, with our improvements to the scheduling graph, we reached a point where performance has become an issue.

In previous attempts to improve performance, I found myself using lodash’s lightweight template function within Angular, which made me feel like I was cheating on Angular. In times when performance was absolutely crucial, I had to write raw JavaScript, which I have no problem writing, but it’s not exactly ideal for quick prototyping or iterating.

Now that our next big feature is time-tracking, I wanted to take this opportunity to try a new approach. What’s exciting this time around is that 1) there’s this new thing called the virtual DOM, and 2) almost every modern framework has adopted it. I was eyeing React last year (because my west coast friends wouldn’t stop raving about it), but it never really resonated with me—especially once you get into the whole Flux, Redux, Muppetdux, Hufflepux thing (those last two aren’t real). At one point, React was the only option if you wanted the performance of a virtual DOM, but one-by-one, every other framework caught on. Now, there are faster frameworks and some with a more familiar syntax to what I’m used to—like Vue.js.

I tried Vue a very long time ago, before it was even 1.0. The creator, Evan You, borrowed a few ideas from Angular and had a similar syntax, so Vue felt like a younger brother to Angular—a lightweight alternative, but not quite there yet. Because of its solid grounding, I chose Angular. While I started building Cushion on Angular, Evan began working full-time on Vue. Fast-forward several years and Vue is the new hot framework. It also feels much more solid than when I previously tried it, and it’s incredibly fast because of the virtual DOM—perfect timing for me.

I gave Vue another shot and was immediately blown away by how powerful it is while still so easy to use. I also appreciated all the nice touches that were added, like shorthands (@click instead of v-on:click) and event modifiers (@click.prevent to call event.preventDefault). Vue is now the lightweight alternative I’ve been searching for, and more importantly, it immediately makes sense to me.

The problem now is that I have years of code written with Angular and there’s absolutely no chance of me taking the time to replace Angular in one shot—especially if I want to make any progress on actual features. As a first step, I wondered if I could take advantage of Vue’s speed by replacing Cushion’s graphs with Vue components. I reached out to Evan—would it be possible to “embed” a Vue component within Angular? Apparently, yes! Evan pointed me to this article that suggests wrapping the Vue component with an Angular directive and using the ng-non-bindable directive to tell Angular not to interact with Vue’s HTML.

I tried using this technique and it does, in fact, work... but it’s not ideal. If I ever wanted to communicate between Angular and Vue, I would need to trigger Angular’s $apply method with every change within the Vue component. While this would be possible with some inconvenience, it didn’t feel right. Even though I could do it, doesn’t mean I should do it. The same could be said about embedding Vue within Angular, but I wasn’t ready to give up. I had one last idea.

Similar to React’s Redux, Vue has its own state management library—Vuex. Vuex keeps the app’s state in a centralized store rather than in the components. In my previous Angular/Vue experiment, Angular would’ve been the centralized store, as long as I called $apply with any changes—and I could only send data to Angular through the directive. With Vuex, a new possibility presented itself—what if I built time-tracking as a Vue app within Cushion? (I know this sounds so wrong, but hear me out.)

Without using Angular’s state management or http services, it serves simply as a router in Cushion. And considering Cushion’s tabbed navigation structure, I could contain an entire app in one of its tabs. Vue’s view model instance is incredibly lightweight and performant, so when a user switches to the time-tracking tab, Cushion can mount the instance and make any requests to the API from Vuex. Then, when the user navigates to a different section, Cushion can destroy the instance and clean up any loose ends. At this point, I no longer need to write hypothetically because I actually did this and it works really well.

I decided to go a step further. At its core, Vuex is simply a JavaScript object that stores data. What if I wanted more than one Vue instance to communicate with each other? For example, if a user starts a timer in the time-tracking section of Cushion and navigates to another part of the app, I’d still want them to know there’s a timer running. As long as Vuex is still available for the timer, I could destroy the time-tracking instance and mount another instance for the timer. Apparently, it couldn’t be simpler.

In Angular, there are providers, which are by far the most confusing aspect of Angular. (After three years writing an Angular app, I still need to reference the documentation for these, and they still confuse me.) One of these providers is called a “service”, which can be used to create a single store to reference throughout the app. All it needs is a function that returns an object. With a single line of code, I can return Vuex as an Angular service. Now, I can reference the Vue app’s state across the rest of Cushion and inject it into any Vue instance by simply specifying the store. On top of that, this opens up a way for me to migrate Cushion from Angular to Vue in steps, rather than rewriting the entire app all at once.

When we’re ready to start migrating other sections of Cushion, I can start treating each section as an app. I could rewrite the Angular controllers as Vue instances, and simply create new store modules in Vuex. Everything remains modular, and I wouldn’t abuse $rootScope as much as I do right now. Eventually, I’d be able to replace Angular’s router with Vue’s router and shake all the excess weight.

So far with Vue and Vuex, I’ve been able to create a much more clearly defined app structure, with state that “can only be mutated in a predictable fashion” (to quote the Vuex docs). I’m also taking this opportunity to ween myself off CoffeeScript in favor of ES6. As long as I’m improving one aspect of my dev life, I might as well kick another habit.

Learn more about Vue & Vuex.