Our Doximity application has gone through many stages of evolution since the first commit in June of 2010. It began as a small Gemfile consisted of Rails 2.3.5, authlogic, paperclip and will_paginate. No micro-services, no Dockerfiles, no message queues, not even much JavaScript.

As we built richer user interfaces, we started writing more JavaScript using Backbone as the front-end framework. One thing became apparent over the years; JavaScript kept coming up in our retrospectives because it slowed down development. Writing features in Ruby on Rails was considerably faster than Backbone but we didn't want to compromise the flexibility we had with Backbone. It was time for us to reevaluate our front-end options.

Luckily for us, the JavaScript ecosystem has progressed rapidly over these 7 years. But porting 105,000 lines of JavaScript wasn't an easy pill to swallow. Without jumping to rash decisions, we decided to take a week to experiment with the popular frameworks that existed. Our initial choices for this experiment were Ember and React.

The Showdown

A group of four engineers took two weeks to build the initial front-end application in Ember and React. This included boilerplate tools we needed such as authentication and assets, and some commonly accessed pages. Thereafter, we sent an email to all of our engineers to take a week implementing specific features within the Ember and React applications. It took a bit of coordination due to engineers being on separate teams but we managed to make it work by staggering it across 4 weeks. Below is the email that kicked it off:

As per an earlier email I've sent out, we are going to spend a week learning and implementing features in Ember & React. Here are the schedules for when you will be working on it and who you will be pairing with. Due to an uneven number of people, there is one team of 3.

I haven't had a chance to check vacations, if you are on vacation that week please let me know ASAP.

[ Group Assignments ]

What To Do:

1. Join #javascript to ask any questions.
2. Spend 1-2 days reading up on Ember and React. Use the resources provided for Ember and React. Pair with your group for any questions or discussions that come up around the material. You will be assigned two small stories to implement a feature in Ember and React. Do both by pairing with your group and submit it as a pull request to the channel. Expect it to be reviewed by other members of the team.
3. Make any updates to the README as necessary to help the next group of people working on it.
4. Take notes on what you found useful, hard, complicated so when we review it weeks from now, you have notes.

If you have questions, reach out to me directly.

The Review

Once everyone finished their implementations, we started sharing the feedback within the team and did a retrospective on this experiment. During the experiment we had two new frameworks that made it into the mix unexpectedly. Angular 2 and Vue were introduced as people had extra time and believed they can also help solve our problems. Needless to say, there were plenty of opinions in the form of 32 lengthy emails, 12 pages of notes and too many Slack messages to count. The decision on our front-end framework boiled down to these five considerations:

1. The community around the frameworks and how active they were.
2. Our feature development process at Doximity. We work in two week iterations and allocate resources often towards spiking new prototypes and split testing new ideas. This was easy for us in Ruby on Rails, and we didn't want to lose velocity in this regard.
3. Ease of implementing features following good design practices without fighting the framework. Ruby on Rails, once again, made this easy.
4. Coordinating work with our design team and leveraging our Vital CSS framework.
5. Writing end-to-end tests, which we never found ideal within a Ruby on Rails application.

For the majority of these decisions, React and Vue met most of our needs. We are all big fans of Ruby on Rails, especially for the convention over configuration aspect of it. React often led us into bikeshedding discussions. But with Vue - it just worked. Therefore, we chose to move forward with Vue slowly.

The Vue Forward

So, how were we planning to migrate our front-end features to a Vue SPA? The plan was going to take the better part of a year but we wanted to approach this cautiously. There was no rush. Here’s how we did it:

1. We knew we had a lot of front-end components that we needed to build or port over from Backbone. Therefore we catalogued the components we had and the ones we would need and began work on these. We weren't implementing any user facing features but simply building the backbone so engineers can focus on building features. We eventually open sourced the project called Genome.
2. We identified all the required features we needed within the SPA to build our pages - from server side rendering, to deployment strategies, to state hydration and created stories to track them.
3. Following this, we had two dedicated engineers working on the SPA implementation to ensure the required feature sets were brought into the mix.
4. Meanwhile, we provided material for other engineers to brush up on ES6 and Vue through online courses and books.

That brings us to where we are now - implementing user facing features with a single MOFO team. Keeping the implementation to a single team will help us continue to polish the SPA while we get our feet wet with Vue.

We could have moved much faster if we wanted to, but there is value in carefully evaluating technologies as they pertain to our business and teams. In this case, we chose to move slower with purpose and not break things.