 Okay, hey everybody. My name is Patrick O'Daherty, and I'm an engineer at Intercom in San Francisco, and today I'm going to be talking to you about how you can start your own Ember revolution at work. So this talk is based on our own experience at Intercom of adopting Ember and migrating a large existing code base into a new Ember application. So for those of you who might be unfamiliar with Intercom, Intercom is the one place for every team in a internet business to communicate with their customers personally and at scale, whether that be on your website, inside your web or mobile application, or even by email, and our mission is to make web business personal. So Intercom started life back in 2011 as a Rails application like any other and grew quickly over the years as a large monolithic code base powering both the suite of APIs for our messenger platform and SDKs, as well as the web application used by our users to communicate with their customers, and back in 2014, we undertook a complete rewrite of this web application, deciding to rebuild it from scratch using Ember. I know that selling the merits of Ember at EmberConf is a little bit like preaching to the choir. I'm sure you're all well familiar with how Ember is going to be able to help your team. But I do want to take some time to give a little bit of background and that went into the decision of adopting it at Intercom. So at the point that we started using Ember, Intercom's web application had grown to comprise of over 40,000 lines of template and JavaScript code alone. And this combination was becoming quite unwieldy at the time. These tightly coupled JavaScript classes ended up being problematic in a number of ways. They were hard to test, they would interact in unexpected ways as they manipulated DOM elements and maybe changed jQuery selectors, that sort of thing. And ultimately, they accounted for a really significant portion of our technical debt at the time. We were also beginning to hit some of the inherent performance limitations of relying so heavily on server-side rendering. As our product pages grew to be more comprehensive and show more and more information, re-rendering each page, querying for the same large dataset over and over for every minor change in rendered output was just unacceptable. And the combination of all of these issues caused us to start questioning our Rails-based front-end stack. This was particularly important as we were planning to expand our product considerably over that coming 18-month period. And we're worried about building on what we were beginning to consider shaky foundations. And on top of that, we felt very much that we had reached a tipping point both in kind of application performance, but also in developer productivity. Zooming out, however, and taking a look at the wider development ecosystem of the time, there had been a considerable amount of change in even the three-year period since Intercom had begun development. In particular, the emergence of numerous stable feature-complete JavaScript frameworks like Ember and Angular and Backbone, they completely changed the landscape for us and offered a whole range of new alternatives to this server-rendered JavaScript augmented development pattern that we had come to rely on so heavily. Now, it's not at all uncommon in industry and especially on sites like Hacker News to find people with a somewhat dogmatic sense of belief in their tools of choice. And while we're still very big fans of Rails at Intercom and we still use it to develop the APIs that power both our new Ember application and our Messenger platform, we did want to be a little bit more practical about our technology choices when it came to this primary web application. Another really important factor that went into making this decision was that adopting Ember allowed us to build much more ambitious products. At this time, internally, we were iterating very heavily on the shared inbox in Intercom, which is one of the more crucial components or destinations in the application. It's where the majority of our users spend a lot of time every day working collaboratively as a team to message back and forth with their customers, reply to conversations, work through issues with customers. It's a really primary workflow and it was really important that we nail it. And I want to give an example of just to compare and contrast the product that we were able to build with Rails and then Ember. And this is a screenshot of the inbox. This is one of the final iterations of the inbox that we made in our Rails code base before we adopted Ember. And to contrast, here is a screenshot of one of the earlier versions of the inbox that we rebuilt in Ember. And I hope it's immediately obvious that it's like a much more ambitious application. You can see much more information about what's going on in your team. There's a lot more information displayed, it's easier to switch back and forth. And this was much more ambitious than anything that we would have been previously able to develop. We thought that things like this were kind of out of our reach. And I really do want to make that point. This would have been really more than impractical to develop with our old development patterns. We wouldn't really have even attempted it. Even with all of the potential benefits of your new tool and framework and all of the sunshine and rainbows that you see in the future, not all teams are very receptive to such large change and certainly managers don't all jump in the light when they hear the word rewrite out of their teammates' mouths. And so all of this adds up to make introducing new tools like Ember somewhat difficult. But I hope that these lessons that we've learned can help you both with the technical and also the social aspects of introducing Ember to your team. So the first lesson that I really want to hammer home is that when you're introducing a new tool like Ember or any new tool in your business, it's important that you create your own hype. Start with your friends, your colleagues, all the people that you work with, chat to them about your new tool, get them excited about it. Have them thinking, this is great. It's going to solve all my problems. And not only that, make them think about how it could be used in their everyday work. You really, really want to gather this bottom-up momentum. And indeed, the story of how Intercom got started with Ember starts with only a single engineer, Gavin Joyce. And so Gavin joined Intercom right at the beginning of 2011 and was originally tasked with refactoring the user data APIs that we use to query and present data rather in the user list in Intercom. And this is a screenshot of the user list as it appeared in Intercom at the time. It's a feature in the application that allows you to view all the users of your web or mobile application and quickly filter them based on either their activity in your application or on information attributes that you record about your users in Intercom. And so Gavin started on this rewrite. And while the backend component of the rewrite was relatively straightforward and fell into place, Gavin kind of hit a roadblock with the, whoa, oh my God, Java. That is the most inappropriate time to ever prompt somebody for an update. So Gavin hit somewhat of a roadblock seeing that decoupling this soup of ERB templates and highly coupled jQuery that we'd written to accompany these old APIs was going to be a really significant like uphill challenge. And in this he saw a really clear opportunity for Ember to provide a much better solution to this problem. So to start this little movement, Gavin put together a really rough and ready prototype of what a user list might look like if it was developed in Intercom. And shared it alongside with this other demo that he'd created called Ember Beats. So Ember Beats is a drum machine application. Gavin's a really big music lover and he made this to really demonstrate just the potential there was for Ember to build really amazing applications. And so he shared this mock-up and the Ember Beats application around the team basically with the aim of convincing everybody that we should give this a shot. At the time, given our experience, JavaScript was kind of an anti-pattern in our minds. We didn't really want to rely on it too heavily. But seeing this demo really awakened us to just how much potential there was to build really great products and really amazing experiences with Ember. And got us thinking about how we might be able to introduce it into Intercom. So based on this, Gavin lobbied for us to start a little experiment. A small team, a small number of engineers to spend three weeks developing a prototype Ember list, a new Ember user list rather. And the brief was very, very simple. To build a new, faster user list in Ember to fail quickly if things weren't going to work out. You know, cut our losses. Nobody wanted to spend time on work that wasn't going to work out. But on the other side, if it was looking like things were going to work out well to plan for success and really give a lot of consideration as to how this would be more widely deployed internally at Intercom. So it might seem a little obvious, but this was a resounding success. Even before the end of the first week, everybody was just really buoyed by the opportunity to use Ember at Intercom. And the user list that this little team ended up building was not only simpler to build and drastically smaller as a code base. It was also much, much faster. Simple actions that previously took around five seconds due to server-side rendering and, you know, refetching all this data were now down to a second or less. And I know while five to one, you know, on a purely numbers basis is relatively impressive, it also dramatically changed the experience of using the user list, particularly as people were able to quickly iterate on the searches that they were doing and really, you know, narrow their user list down to exactly the people that they wanted to message. You know, this was just so much better than previously where every minor change was a five-second turnaround. You'd lose the context, it would flash, you know, this was just chalk and cheese. It was really, really much better. So the next thing that I want to talk about is, you know, when you're starting a rewrite or introducing a new pattern or technique, it really helps to form your own internal team of experts, you know, for the rest of your engineers to kind of gather around and use as a resource. So almost immediately after the user list experiment wrapped up, we made the decision to completely junk our existing roadmap of the time and put all of our efforts into rewriting all of the product that we had in Ember. And, you know, facing down this long rewrite road, it was quite a daunting prospect, and it was made more so by the fact that, you know, Barr Gavin and the very small group of engineers that had built this user list, nobody internally had a lot of expertise or experience developing with Ember. And so, you know, we wanted to build resources to, like, form this little small team. We kept them together to provide kind of like a reference point for all of the other product teams as they took their own parts of the application and started planning how they would build their own features in Ember. And this was really, really crucial to kind of like getting the ball rolling and, you know, allowing people to, you know, plan for success and not make simple mistakes and have to throw out a lot of work. We also recruited outside help in aiding to build this, you know, bootstrap this expertise. And we asked Tom Dale to join us for a few weeks as we began this rewrite in earnest. So when you start your rewrite, obviously you have, you know, your end goal in mind. You want, you know, product A but in new technology. But it's important to keep in mind that you're also racing towards this goal, this tipping point where it becomes easier to build new features and products exclusively in your new application as opposed to, you know, adding them to your old. And, you know, we were very conscious of time, you know, at this point. And we wanted to make sure that each of the product teams had every opportunity to, you know, get started and build up some early momentum as they, you know, took ownership of each of their own product features and migrating them one by one into Ember. We also wanted to make sure, you know, that they were free to focus on this, you know, without any of the other distractions that might have been provided by, you know, maintaining the old code base or working on issues, anything like that. We really just wanted to clear the path. And so, like with all rewrites, big or small, you know, there's going to be this kind of awkward period of, like, code duplication. And there's a real risk that if you don't manage your time well and if you don't think about it a lot, that you might end up prolonging this. You know, every line of code that you add to your old code base should be viewed as technical debt because what you're actually doing is creating more and more work for your team to, like, move this into your new application. And so to prevent any, you know, accidental prolonging or, you know, needless time waste of this kind of period of double work, we decided to effectively freeze feature development on the Rails code base and just completely clear the path for the product teams to focus entirely on this Ember migration, which brings us to my favorite lesson, lesson number four, fake it while you make it. So it's important to, you know, as with any product, to get it into the hands of your users early on. You want to get your Ember rewrite out the door as quickly as possible, you know, allow yourself to fix bugs, iterate on things, catch them early, all of that. And shipping a giant rewrite all in one go, you know, it's just, it's a really daunting software task. We're not very good at it. It's much riskier you end up dramatically increasing the likelihood of, you know, shipping multiple bugs at once and otherwise causing a, you know, a really bad customer experience for people who, you know, get on this early alpha. But, you know, when you're rewriting an existing web application, you actually have a lot of freedom. Because you're replacing existing pages, you can actually be pretty cheeky with what you deploy. And indeed, we decided to take advantage of this a lot as we shift early parts of our Ember application. So, you know, given the fact that you're replacing all these pages that already exist, you can actually, you know, mix in bits of your new and old code base together. And so, you know, you don't have to ship it all at once. You can entirely ship, you know, one page at a time and use your existing code base to kind of give the illusion that you've built this massive product, you know, all very quickly. And so, when we were released, rather, the new Ember user list, we very deliberately left out a considerable portion of functionality. And this just gave us a little bit of time, you know, to catch your breath and focus on getting things done right first. And so, to give an example, here is the user list as we originally shipped it in Ember. And I want to point out that all of the functionality on this page, you know, the main functionality of looking at your users, sorting them, filtering them, saving segments, switching between them, all of that, that was all, you know, that was the core of the Ember application. And all the while, all of these other pages, you know, in our product, they were still running this Rails code base. And so, the vast majority of the links on this Ember page actually directed you back into the Rails application. So, for instance, if you wanted to create an auto message to the users that you just filtered, or if you wanted to, you know, check your conversations and see, you know, how people were responding to messages, or catch up on your manual or auto messages, see their progress, monitor their statistics, you know, all of these pages straight through to the settings and documentation, they all didn't change at all. They were, you know, completely the same as before, all in our Rails code base. And so, this allowed us to, you know, feature by feature, move things into Ember, you know, with providing the same experience to people. Another really amazing tool, and I think sometimes web developers have this, they're kind of hesitant to use iframes. Certainly, they've gotten a lot better in recent years. And they were a really invaluable resource during this time, as it allowed us to mix new and old parts of the application onto the same page. And so, we made very heavy use of them in our Ember application to render some of the Rails pages that we had been maybe slow to migrate into the Ember code base. And we would render these pages in components in various Ember writes. And so, this was great at giving the illusion that all of these pages that you were navigating to, you know, very quickly back and forth were all in this one Ember application. And you can also use it to go the other way. And so, we made somewhat creative use of iframes to embed the Ember application into our old Rails app. And the one really strong use case that we had for this was some of our payment flows are modal-based. And so, we wanted people to experience, you know, the same purchasing experience in InchCom no matter if you were in the old Rails code base or in the new Ember one. And so, we would do this by rendering a hidden iframe on the page, booting the Ember app in the iframe. And then any time that you wanted to enter any of these modal experiences, we would open this specific modal write in the Ember application and overlay the frame on the page, giving the impression that all of this was being driven, all of this live experience was being driven by the Rails application. Another really wonderful choice that we made that really saved us was that we decided to keep the URL structure in the application exactly the same as it was in the Rails app, you know, as we moved pages into Ember. So, for example, this is a URL for the page that shows your default user segment where you go to see all of your users. And this is in the Rails application. And this is the same URL, but for the Ember-based page. The only difference being that we would prepend this small prefix to the path to direct users to this new Ember experience. And this doesn't seem like much, but coupled with a feature flagging system, this allowed us to application by application opt people into this new Ember experience. And this was great for controlled rollouts. You know, it allowed us to experiment internally without any danger of, like, releasing accidental bugs. But more importantly, it allowed us to, you know, grow the audience of our Ember application as our confidence increased. We've talked elsewhere and, you know, we've written a number of blog posts on our really heavy reliance on continuous integration and continuous deployment at Intercom. And this pattern allowed us to iterate really, really quickly on the Ember application as we built it. It wasn't uncommon, and it still isn't uncommon, rather, to ship new releases of the application dozens of time a day. And, you know, this was really important for us because we wanted to be able to move quickly, but also in confidence that we weren't, you know, introducing bugs and shipping, you know, awful, awful broken experiences to our users. And this pattern is something that we, you know, we developed previously but really, you know, refined in our migration to Ember. And it's been something that has allowed us to really move quickly with Ember in the approximately two years since we've adopted it. So here's a short timeline of the, you know, product development that we wanted to do in the 18 months after we started using Ember, starting all the way back with the user list in April 2014, straight through to the end of last year. And, you know, betting on Ember has just been instrumental to all of this change. You know, so many of these features were going to take, you know, twice as long if, you know, if not longer to build in this Rails code base. And the patterns and conventions that Ember came with, all of these great decisions made out of the box, just promoted this, like, really quick pace of work. Oftentimes many of these features were able to make very heavy components which Ember, like, really gets, you know, really does it well. And it's just been a great pattern of code reuse all the way through the application, which is great not only for speed, but also in providing this, you know, consistent experience all the way throughout the application. And so I want to leave you just with these four lessons. They've been really instrumental in guiding us through our own Ember journey and looking back, embracing Ember has been probably the best technical decision that we've made as a company. We've built one of the largest Ember applications in deployment in the last two years, and it's been a fantastic journey, like, each step of the way. And so I hope that these lessons, you know, hopefully they'll resonate with you and they'll also be helpful with you as you start your own Ember Revolution at work. And so with that, I'm going to wrap up and thank you so much for your time. It's been really great to have an opportunity to share all this with you. If you have any questions, please feel free to reach out to me either on Twitter or via email. You know, we'd love to help. We very much believe that the more people using Ember and better tools, the better for us all. So thank you.