A bigger Ember tent

I wanted to make something very clear, in response to @mfeckie’s Are we (still) a welcoming community? thread.

In the Ember community, dissent is not just tolerated, it is encouraged. We will fail if people believe they have to stay silent when they disagree with the core team or community consensus.

I want to quote from one of my blog posts, all the way back in 2013:

Developer communities have a habit of crafting mantras that they can repeat over and over again. These distill down the many nuances of decision-making into a single rule, repeated over and over again, that the majority of people can follow and do approximately the right thing. This is good.

However, the downside of a mantra is that the original context around why it was created gets lost. They tend to take on a sort of religious feel. I’ve seen in-depth technical discussions get derailed because people would invoke the mantra as an axiom rather than as having being derived from first principles…

Mantras are useful for aligning a developer community around a set of norms, but they don’t take into account that the underlying assumptions behind them change. They tend to live on a little bit beyond their welcome.

The topic at the time was “progressive enhancement.” Ember has been around long enough now that we’ve since developed our own mantras. We need to make sure that the ease of falling back on those mantras doesn’t cause us to lose sight of the bigger picture. When we engage with other community members, particularly those who are new, we need to ensure that we’re understanding and validating their unique circumstances, not shutting them down with terse dogma.

Ember is also a big tent. Even though each new app comes with the same set of defaults, it’s unrealistic to believe those defaults are right for every situation.

To quote from the Rails doctrine:

As with anything, though, the power of convention isn’t without peril. When Rails makes it so trivial to do so much, it is easy to think every aspect of an application can be formed by precut templates. But most applications worth building have some elements that are unique in some way. It may only be 5% or 1%, but it’s there.

With so many controversial ideas to its credit, Rails could quickly become an insular group of ideological hermits, if we required everyone to exhibit complete deference to all tenets, all the time. So we don’t!

We need disagreement. We need dialects. We need diversity of thought and people. It’s in this melting pot of ideas we’ll get the best commons for all to share. Lots of people chipping in their two cents, in code or considered argument.

There is no “right way” to build an Ember app. You are not “doing it wrong” if you want to use GraphQL or Redux or MobX or TypeScript or Flow or Mocha just because that’s not what comes out of the box. No one but you knows whether a particular tool will make you and your team more productive.

In fact, you’re actively contributing to Ember because experimentation is a fundamental part of the process of incorporating the best ideas from around the JavaScript ecosystem. If people think they’re going to be scolded or made fun of for using the “wrong” technology, they’re going to take their ideas elsewhere, and it will be our loss.

Now that I’m a little older and a little wiser, let me say: mea culpa. I’m sorry for the times I’ve been flippant about other technologies, because it set a tone and a culture that we need to get past. The React, Angular, and Vue communities, and the wider JavaScript ecosystem, are doing incredible work, and we do a disservice to ourselves if we don’t follow along and borrow their good ideas.

We will continue to add primitives and stabilize private APIs in Ember, so that it’s easier for you to integrate with other tools while preserving the compatibility and shared solutions we value as a community.

While that happens, I have a request of you: whether it’s on Twitter, Slack, Discourse, or anywhere else we gather, validate the pain people are experiencing. Before getting defensive, acknowledge their frustration and offer to help—which has a tendency to defuse the situation altogether. If someone shares an experiment or an idea, encourage it or provide constructive criticism that is respectful of the work they’ve already put into it.

And if you see me or anyone else getting this wrong, call it out (gently). It’s a bad habit that’s easy to slip into, and we can only change our culture if we all help each other spot it when it happens.

As Sir Jony Ive said, “While ideas ultimately can be so powerful, they begin as fragile, barely formed thoughts, so easily missed, so easily compromised, so easily just squished.”

Let’s make sure we’re fostering a community that doesn’t squish ideas.

Would love to hear your thoughts and feedback.


I have very little to add here, because Tom nailed it in so many ways.

Most of my personal contributions to Ember over the years started from understanding (really understanding) how people do work in other ecosystems, and why people sometimes feel more productive when working in those ways.

When someone tells me that something feels painful in Ember, or that some other environment feels so much better, I am honestly excited by the conversation, because it gives me an opportunity to drill down into their lived experience to learn things that aren’t part of the marketing message of those frameworks.

Those conversations led to deep insights into the nature of our work, and led to the complete adoption of the React “single-pass render” programming model that ultimately made it a hard error to mutate parts of the DOM that had already been rendered in the same pass. In earlier days, you needed to wait for your render to “settle” as data ping ponged around in the binding system.

This was a huge improvement, and it came from listening to the experience of React developers, and trying to understand deeply what aspects of the React system resulted in improved productivity. But it always starts with listening, and derision shuts down the kinds of conversations that lead to these advances.