In October 2015, the UI team at Verizon Digital Media Services started to reenvision the next generation of the Media Control Center, our customer facing CDN portal. The MCC was started in 2008 and is a traditional server-rendered application built on the .NET technology stack. Over the years, the front-end started playing a more prominent role using JavaScript technologies including jQuery, Angular 1, Gulp and CoffeeScript (popular at the time). Even though modern front-end tech was used, there were several pain points that frustrated front-end developers, leading the team to start thinking about how we wanted to build out MCC. Should we continue with Angular 1 and hope to switch to Angular 2 if there is an upgrade path, or should we switch to something else?

Our Challenges

Before choosing a framework, we identified our challenges so that we could choose the right tool for the job.

The first challenge the team experienced was testing. We had 0 tests. Every change to a project had to be manually tested by the developer and the QA team.

Second, there was no consistent API mocking solution. Many times our UIs were developed in parallel with the APIs, so front-end developers often couldn’t hit a remote endpoint. Instead, each developer crafted their own API mocking solution whether it was using plain JSON files, an Express server, or a library like Restify. Each project solved API mocking its own way, and some solutions had lots of custom code to simulate server-side persistence. This made it very difficult for newcomers to start tackling tickets when joining a project.

Third, there were many inconsistencies ranging from project structure and code style to Gulp files and naming conventions. Several of our front-end apps went through many hands of on-site and remote developers following different conventions. This further increased the ramp-up time for onboarding developers on a project.

Lastly, our build tooling required frequent maintenance, and no one enjoyed modifying a 400+ line long Gulpfile. Bugs that came up in the build process were difficult to debug and took time away from building features and fixing bugs in our sprints.

Deciding on Ember

After much discussion of our challenges, as well as weighing the pros and cons of different frameworks, the final contenders were: sticking with Angular 1, with potential hope of upgrading to Angular 2, and Ember. Not everyone on the team was experienced with Ember so we took a week to educate everyone and gather their feedback. Finally! The results were in. We decided to move forward with Ember.

Our decision was further justified with the fact that large companies like LinkedIn, Sony (PlayStation Now), Apple, Yahoo and Netflix had also invested in Ember for some of their major products.

How did Ember solve our challenges?

So, how did Ember solve the challenges we had faced?

1. Testing Infrastructure

First, Ember provides an out-of-the-box testing framework. As the user interfaces of our portal applications were getting larger and more complex, we knew we needed to make testing setup simpler, and less impactful on feature development. Angular has Karma and Protractor, but setting up a good test harness for Angular applications was difficult; lots of setup is required. Thanks to Ember CLI, we could have a full test harness for unit, integration, and acceptance tests in seconds. Additionally, because Ember CLI autogenerates test boilerplate for every single module that you create, developers would likely be more proactive in testing.

2. Ember CLI

Another motivation for switching to Ember was the productivity gains that came with Ember CLI. With our Angular applications, our build processes were using Gulp. Each Gulpfile was very long and often times different. Ember CLI removed the hassles of building our code and let us focus on the actual features of our applications. Linting, ES6 transpilation, template compilation, minification, concatenation, fingerprinting, and live reload all came for free. Furthermore, Ember CLI gave us a prescribed project structure and generators. Each of our projects would have the same directory structure making it easier for developers to hop between projects and reduce the ramp-up time for new hires. Using third-party libraries also became a breeze because of Ember CLI Addons. With this switch, we’ve been able to hire two great Ember developers who have been productive since day one because of these shared conventions.

3. A Community-Driven API Mocking Solution

As mentioned above, a big challenge we faced was having a standardized API mocking solution. Thankfully, the Ember ecosystem has Mirage, which allows us to quickly generate a mock API layer using fake data or fixtures and simulate server-side persistence without lots of custom code. Again, more conventions and shared solutions.

4. Backwards Compatibility

At the time we made this choice, Angular 1 was mainstream but Angular 2 was pre-beta. There was word that Angular 2 would not be backwards compatible and the upgrade path would be difficult. Ember’s strong emphasis on backwards compatibility and not leaving anyone behind, really resonated with our team, as we didn’t want to have to rewrite our UIs because the framework we had chosen was no longer supported.

Ember has an established process for upgrading between major and minor versions of the framework. Ember provides deprecation warnings in development mode so that you know what features will be deprecated in the next major release. Not only has this been beneficial for keeping up with the evolving framework, but this has allowed us to attract developers who want to work with the latest tech.

Retrospective

Initially, switching to Ember meant rewriting a few of our applications. Because there was no new feature development for a short period on some applications, it was a short-term loss for a long-term gain. Since the switch, the UI team’s productivity with maintenance and new features has significantly increased through the framework’s philosophies, shared conventions, community and tooling. The quality of our code has increased as we’ve been able to embrace testing, continuous integration, and an Outside-in testing process where our development is driven from user stories.

Shortly after switching to Ember, the company decided to standardize API development and chose the JSON:API specification as the foundation (Editorial note: blog post coming soon). Thankfully, Ember Data supports this out of the box. Although the company did not decide to use JSON:API as it is, the integration with Ember Data has mostly been a breeze, due to Ember Data’s flexible abstractions consisting of models, adapters and serializers.

We’ve chosen Ember as our framework for the long haul and we’re looking forward to what we can achieve!