Coauthors: Sarah Clatterbuck, Mark Pascual, Chad Hietala, Eugene O’Neill

When setting out to re-imagine our flagship app and desktop web experiences last year, we wanted to make a move to a more modern technology stack. We were falling behind in a few areas and wanted to address the following points of concern:

Responsiveness

Modern web apps are typically heavily client-rendered to provide the user with a more responsive user experience. The design team wanted to create page transition experiences, which are not possible in traditional web pages. When a traditional web page is requested, the browser loads it suddenly and jarringly as the response is fulfilled. Conversely, in a client-rendered app, transitions can be made to elegantly fade or slide in, because the Document Object Model (DOM) of the existing page is being replaced rather than a new page being requested from the server. Also, we wanted our desktop member experience to be more app-like and aligned with the native mobile app experience both for consistency between platforms and snappy-feeling interactions.

State management

In our patterns for addressing JavaScript in web pages, we had great conventions around widgets and DOM manipulation. However, where things got really complicated was when we needed to manage state. There were a number of hand-rolled solutions to managing state along with several imports of various libraries to do the same. This led to a fracturing of our frontend ecosystem and an inability to provide adequate developer tooling for developing with these more complex tool sets.

Developer productivity

In addition to creating an easy way to manage state, we also wanted to provide greater developer productivity. This included the ability to go from writing code and tests to deploying in several hours. We also wanted to bring together our fractured frontend ecosystem into a single set of conventions that all the teams developing long-lived stateful apps would follow. In order to get to the level of productivity desired, we also needed a robust set of tooling for creating dev and production builds and writing unit and acceptance tests for JavaScript.

The solution: Pemberly

We decided to build up a solution, dubbed Pemberly, combining open source software we were already using in the mid-tier (Play) along with a web framework (Ember) for JavaScript that would deliver strong conventions, easy ability to manage state, a robust build and testing methodology, and the delightful, app-like user experience we were targeting.