I still vividly remember the spring of 2014, when the foundation was laid to what has been the biggest technology and culture transformation initiative yet at British Gas digital. A small group of highly passionate individuals knew there had to be better answers to the challenges we were facing and we wanted to change for the better. Our frustrations with the status quo weren’t unfounded. We had a super tightly coupled, server heavy, monolith web application powering www.britishgas.co.uk, along with orthodox enterprise processes that made the whole thing expensive to manage, slow to deliver and left very little room for innovation. We had next to nothing in terms of in house development capability/culture and were just basically on lookers as the rest of the world raced past with modern tooling and practices that were simply better.
Fighting against the status quo isn’t the easiest of things, especially when it has settled in over the course of many years. Everyone is simply used to it and change is hard. We had to change by example. The scope of what had to be changed was enormous. Here, I’ll describe how Ember came to be part of all this and how it has been key to the success we’ve had in the past 2 years.
Clearer separation of concerns
Choosing the SPA framework
I had the enviable (or not so enviable!) job of choosing a JS framework for our single page applications. At the time in 2014, I had done a lot of work using Backbone.js. We had a sprinkling of Backbone based widgets/mini-apps across www.britishgas.co.uk and I liked its simple and minimalistic nature. Minimalism though comes with a cost. It is immensely satisfying as a developer to build a system from a minimal set of abstractions but in reality it also means you need the extra bit of time which you would rather spend on building the actual features on your customer facing product. You also find that by bolting on various bits along the way, you no longer have the minimalism you once had. It’s a fine balance and you needed to find the right tool for the type and scale of applications you intend to build.
Looking beyond Backbone, Angular and Ember stood out as broader application frameworks better suited to larger applications. Angular was the most popular framework by far then and a combination of its popularity and the backing by Google made it the ‘obvious’ choice. It also meant that Angular skills were not in shortage. Ember was unassuming at first glance. Its adoption rate wasn’t anywhere near Angular’s yet it seemed to have something about it that warranted a closer look. It had some brilliant minds behind it, placed a lot of importance on convention, had well thought out opinions and Ember CLI was building up to be a great command line companion offering baked in project structure, build and test capabilities, ES6 support, an integrated addon system, useful generators and an API to extend it for your custom needs.
Ember Data offered a useful structured data access layer based off an object relationship model.
“Eventually all the good ideas will end up in Ember” Yehuda Katz
Top it off with what we found to be an extremely helpful community and we decided it would be the framework of choice for our applications. In many ways, we took the road less travelled by but as Robert Frost said, it does make the difference.
Towards the end of 2014, about 3 months after we had started off, Angular 2 was announced at ng-conf and it was to be a total rewrite with a brand new programming model and no established migration path from the popular 1.x series. The Angular team have since announced migration paths but the original announcement was a bitter pill for the thousands of apps built on the framework’s 1.x series. An announcement that vindicated our decision to choose Ember over the popular choice at the time.
How its gone for us
Over the past 2 years, we’ve moved all our core customer facing web apps into Ember. Online account management, energy and services sales, moving home are all capabilities we now deliver through an Ember application.
It’s no secret that it has a steeper learning curve compared to some other frameworks but once you’ve got over that, it makes you a really productive developer with its conventions and opinions acting as useful guard rails. Features get delivered to the market quicker.
Ember CLI has well and truly established itself as a trend setter and has inspired similar initiatives for other libraries/frameworks including React(Create React App) and Angular(Angular CLI).
The addon eco-system is massive and the emberaddons website along with its ember observer score makes it easy to find the right one for your needs.
We have complex combinations of customer types to handle and ember-cli-mirage by Sam Selikoff has been a boon for us to mock them for development and automated tests. Addons also allow good ideas from other libraries/frameworks to be plugged in to your Ember apps. ember-changeset (inspired by Ecto changesets/authored by Lauren Elizabeth Tan) and ember-redux being cases in point. Real world solutions for real world problems.
We had a smooth transition to the 2.x series when it came about as the transition path was well communicated in advance and there were addons that helped with the transition (ember-cli-deprecation-workflow, ember-watson).
I’m a massive fan of React’s component model with it’s focus on composability, one way data flow and explicit mutation creating a simple yet powerful programming model for user interfaces. I can’t help but quote Dan Abramov’s classic You are missing the point of React. These are principles that you can adopt in your ember applications as well and with the impending arrival of Ember’s Glimmer 2(the new rendering engine) and angle bracket components, the solid principles that React has brought to the development community should be easier to incorporate in your Ember application. A fine testimony of the framework’s commitment to ensuring that good ideas are brought to its users regardless of where they originated from.
We have a suite of Ember applications currently as opposed to one large application and Ember Engines is going to allow us to compose them in a better way for our customers. Engines will allow multiple logical Ember applications to be mounted/loaded on demand and thus enable a seamless transition between our applications for customers (as opposed to the current experience of a page refresh between transitions), in addition to providing performance gains. Our first engine is now ready and should be launched to production in the next 2 weeks.
Couple engines with other initiatives like fastboot and upcoming RFCs like the below and you can see that improving performance is a key area of focus on Ember currently and its something we are really looking forward to. We keep moving forward together with the framework.
Ember’s community is amazing and we make sure we give back to it whenever we can. We sponsored EmberCamp London in both 2015 and 2016, released addons and love going to the Ember London meetups to see what fellow engineers have been up to.
In summary, we’ve had a very satisfying time with Ember over the past 2 years as part of the wider transformation initiative and we look forward to having more going forward. It has been an often understated but key ally in our efforts to move forward quicker and stronger.