I Love Ember. Our Team Decided to Switch To React. And I’m Ecstatic
At ASH, we love Ember. But we’re not totally in love with Ember anymore. We’ve been inseparable for seven years. The honeymoon phase faded a long time ago, but even after that we still had a great time with Ember. It’s a great framework that can, and is used to build some pretty great applications like Apple Music, LinkedIn, PlayStation Store, Square, Discourse, and more. We used it to build most of our websites, which are composed of shared components all written as Ember Engines or addons. Those components get assembled together like Lego blocks, in whatever shape you want, to build the websites we use, both internally and externally. We love Ember. I love Ember. I just don’t know that I’m in love with it like I used to be.
Ember, We Need To Talk
While Ember served us well, a few years ago something happened that shaped where we are now. Some teams didn’t feel like it was the right tool for their needs. One of the reasons was they felt a lack of online support, when they needed it. So they went with Angular, another very capable and even more popular framework that those teams already had experience with. The problem came later, when the projects needed to integrate with each other (initially, there were no plans for this to happen). The teams were able to make it work, but we were never fully satisfied with the solution. The websites contained fragmented routes and, in some cases, teams had to develop duplicate features in both frameworks. We didn’t like the feeling of having two partners — it was time to choose one.
Plenty of Fish in the Sea
If we only limited ourselves to Ember and Angular, we’d have the option of two great frameworks. But what if there was something else out there for us? Choosing to commit to one framework is a big decision. We wanted to make sure we made the right choice. There were more choices now compared to when we first chose Ember. Not to mention the fact that we’re a different company than we were when we chose it. We looked at all the choices out there, but ultimately, we settled on narrowing down our options to Ember, Angular, React, Vue, and Svelte. We also took a peek into Blazor and Flutter, out of curiosity and intrigue, but quickly decided that the choice was between the first five.
It’s Not You, It’s Us
Let’s be clear. We could build any of our apps with any of these frameworks. They would all work. Users would still be able to register and search for gyms. Practitioners would still be able submit claims and contact us. Call center reps would still be able to look up member information or enroll them in a program. It’s not that Ember couldn’t do it, but we had some concerns with it.
Ember has a great core team that does a great job of communicating the direction of the framework and listening to the community. It’s not owned by a single company like Angular and React are. But there are companies that are heavily invested in, and have a lot of core team members, namely LinkedIn, contributing to Ember. And they’ve done a great job of keeping Ember open, modern, and updated. But what happens if LinkedIn changes their minds too and chooses to use a different framework? The Ember community is small, but strong. It would lose a significant piece of its community. And one of our concerns is that there aren’t the same number of developers in the community to fill the void as could happen if Facebook stopped using React.
Furthermore, answers and support are not as easy to find as it is with other technology. Ember moved its main community support platforms to Discord. Let’s be honest, a lot of engineers look to Stack Overflow when they can’t find an answer in documentation (ok, or even before documentation in some cases). There just isn’t very much updated content on Stack Overflow for Ember.
Combine that with the smaller community, and it can be tough to find answers to issues. Similarly, if you’re looking for a course or articles about Ember, you can find them. But the amount that are up-to-date just aren’t on par with other frameworks. Granted, if more people from the community (admittedly, like me) stepped up, this could be better. But the demand isn’t there to drive the supply as much as it is for other frameworks. It’s not a judgement on the community or team, just an observation from listening to other developers that I’ve seen.
The bottom line: Ember help, especially for newbies, is becoming less accessible and has a little more friction to get to versus other frameworks.
Ember.Object for each component, so we didn’t even have a choice. Dynamic imports and lazy loading routes weren’t available unless one used Ember Engines (which we do, and love) or until ember-auto-import was supported. And, if an engine supports lazy loading, it had to be a breaking change for teams integrating it. Meanwhile, I would spend the beginning of my morning reading articles introducing features in other frameworks and feel like Ebenezer Scrooge standing in the cold, peering into the window and watching everyone celebrate Christmas inside.
So what’s our React replacement solution for Ember Engines and the features we love about them?
Unlike Ember Engines, with React Router, we’ll be able to lazy load any other team’s component without them needing to enable anything. The significance of this change for teams building distributed components shouldn’t be lost. Currently, if Team A owns an engine (not lazy loaded) that is mounted in Team B’s Ember application, Team B may see the opportunity for a performance improvement and request a task to enable lazy loading…in Team A’s backlog.
Team A then needs to prioritize this and make the changes, distribute the new (breaking) version of their engine to all the teams that use it. Each team, not just Team B, then needs to install the latest breaking change into their application. Meaning Team C, Team D, Team E, etc. need to add tasks to update to the latest (now) lazy loaded engine. What if some teams are not able to update the engine immediately? Team A would need to have a dual maintenance window to support version 1 and 2. It’s pretty easy to see how this erodes productivity and morale. Engineers would rather work on the larger, more complex problems.
Going further, we can finally lazy load our own components in our apps to reduce bundle sizes with React.lazy. This is something that isn’t supported in the main features of ember-cli at this point. As a leader, it’s hard to put too many performance expectations on the team when our main framework makes some of those efforts more friction than is ideal. Automatic tree shaking is something we’ve been wanting for years — and now it’s available to us!
The bottom line: React seems to push out more modern features that fits our needs faster, and with less friction.
So Many of the Good One’s Are Taken. Or Don’t Want What We Have To Offer
We have never sought out somebody whose knowledge was specific to Ember, nor did we require Ember experience. And we won’t require React experience or look for people whose knowledge is specific to React. But, as much as it can frustrate me when somebody only wants to work in a specific framework, the truth is there are sometimes good reasons for this. Some engineers are scared of going to a new job to work on a framework like Ember, and feeling that they’ll be out of the loop with other mainstream tools. My hope is that other companies are hiring based on skills and fundamentals and would still look at those candidates. But the fear out there is real and, sadly, using Ember has limited our pool of candidates.
The bottom line: One of the items we considered with choosing a framework was its impact on recruiting. And that hurt Ember’s ranking in our list.
It’s Too Big a Big Commitment
One of the great things that happens after you run
ember new [appname] is that you have most of the tools you need for a complex application ready for you to use. Routing, testing (unit and UI), API fetching, and state management are already installed and guaranteed to work with each other. Until you use another framework and have to figure out which tools to use (we’re in this process now), you don’t realize how great this is to have. Especially if you’ve waited until after your project has started to scale bigger.
Having all these tools already installed means you should read the docs and learn them before getting started with a project. And they’re (mostly) proprietary to Ember. So if you’re using the out-of-the-box tools (e.g., Ember Data) but you’re familiar with Redux, you can either install a third-party addon (oh, and hope it’s stable and maintained) or learn the Ember default. It’s a lot of new tools for new engineers to learn right off the bat and means that you’re probably going to become more ember-centric in your tech stack knowledge. It also lengthens the ramp up time for projects and new engineers.
The bottom line: Ember’s unique toolchain sometimes prevents some engineers from easily adopting the tools they’re familiar with and takes longer to get ramped up.
We’ll Never Forget the Times We Had
Ember has been great. It’s made all of us who use it better engineers and taught us a lot. We’ve used it to build sites that help people get healthy, improve their lives, and simplify their fitness. I have, and would still, encourage people to use it, if it fits their needs.
But the fact is, we’re a different organization today than we were when we adopted Ember. And our needs have changed. I hope others out there continue to use Ember. And Angular. And all the other frameworks that exist today and come along in the future. The more options there are (in moderation, of course), the more they can all continue to learn from, compete with, and help each other, so that they can all continue to become better tools. And, in return, make the web better.
We love you, Ember, but it’s time to move on. It’s not you, it’s us.
So how did we decide to make the change?
When we started, we had a large group of different teams that documented their pain points and hopes for the yet-to-be-determined unified framework. We scored each framework against those needs and requirements, and React came out as a pretty clear winner.
At ASH, we don’t have dedicated architects. We have a group of senior engineers from each product team, who assemble weekly to go over new team needs and recommend solutions. With the framework selection, we used this group’s process and ran decisions through it. But the group was also made up of anyone who wanted to join, including mid and associate level engineers. Those engineers then began working on a recommended migration path for teams, as well as deciding which tools would replace our current Ember (and Angular) tools.
I’ll write more about that in a future post. For now, let’s just celebrate the good times we had with Ember and look forward to the future with React.
And, if you’re interested in joining us for this journey, we’re looking for a Senior Front End Engineer.