I'm writing this near the end of the official #EmberJS2019 window, which means a lot of what there is to say has already been said. As I've read through this year's posts, there are a handful of themes I see coming up over and over again:
- streamlining and modularizing the framework
- broadening the Ember community
- landing our new build system, Embroider
These points are each important and valuable in their own right, and I'm hopeful that the 2019 Roadmap RFC will address all of them. Many of the posts discussing them, though, brush up against something that I think merits a more explicit discussion.
Over the past couple years I've seen an increasing number of Ember folks display a mentality that divides the world into Us and Them. It manifests in social media interactions and blog posts, day-to-day chatter in the Ember Discord server, and even the way we frame meetup and conference talks. I think it's driven by a desire to see Ember succeed and to convince other people that they should like this thing as much as we do, but it ultimately does everyone involved a disservice.
What those three bullets above have in common is that if we achieve them, they may each help us begin dissolving this mindset. Broadening our community means bringing in developers with experience with other tools, which can blur the line between the ingroup and the outgroup. Streamlining the framework and adopting Embroider will better align us with standard practices used throughout the wider Web ecosystem.
My hope for #EmberJS2019, though, is that we'll take that a step further and make an active effort to tear down the Us and Them mentality, deliberately engaging with the broader Web development community.
Why Are We Divided?
Why do we as a group self-identify as a group? There are some historical technical things that pushed us in that direction, as well as some general sociological phenomena1 that may have helped shape and reinforce that grouping.
Technical Reasons
A big part of what makes Ember valuable as a framework is the strong conventions that pervade both applications and published libraries built on it, and that would be impossible without a community of people who own and embrace those conventions. In fact, that desire to have shared, consistent solutions is at the root of some of the technical reasons we've historically been separate from the rest of the Web ecosystem.
Ember's rich object model predates the introduction of classes as a language feature, but once classes were part of the ES2015 specification, much of the rest of the Web development world adopted them. Years later, idiomatic code still uses the original Ember object model, because ES classes by themselves aren't expressive enough to capture the same meaning.
ES modules were a similar story: the Ember team made an early bet on them back when much of the JS tooling effort was focused on figuring out how to bundle up CommonJS modules for the browser. Of course the bet on ES modules turned out to be a good one, as it's increasingly become the no-questions-asked default, but in the meantime a whole lot of code was published in CJS format and Ember developers were left either needing to write complicated build code to pull those libraries in or just roll their own following Ember conventions. An entire class of ember-xyz addon was born whose sole job was to get the xyz library into your build without manual configuration.
Thankfully, neither of these two things are true today. The upcoming Octane edition of Ember will encourage the use of ES classes (thanks to the class fields and decorators proposals) across the board, and ember-auto-import makes the process of including 3rd party libraries in your build trivial regardless of the module format they use.
For a long time, though, not having these things was the status quo, and it meant that code written for an Ember project didn't look like code you'd write in any other. If the code you develop in one context isn't usable in another, it's natural for development between those two contexts to begin to become isolated. Norms will drift, different solutions will evolve for similar problems, and you ultimately wind up with bodies of practice that look very different from one another.
Sociological Reasons
Of course, technical factors are never the only ones at play. The tendency of people to naturally group into Us and Them is a pretty well-studied sociological phenomenon, with the end result that social groupings can be a self-reinforcing structure.
To be clear, it's a good and healthy thing that we have an identity as a group. In the EmberConf keynote this year, Yehuda Katz talked about the Celery Test as a way of ensuring you're acting on your values when deciding how to build something. Ember as a framework prioritizes a certain set of values in software development, and that means as a self-selected group of people who use Ember, we typically also share most of those values.
Because we have a shared understanding of what we as a community consider important, we can often skip straight to the heart of a discussion, since many of the decisions that might normally lead off on bikeshedding tangents are already tacitly agreed upon ahead of time. We can also know when looking at a public addon that its design is likely the result of decisions similar to those we would make ourselves.
All of this promotes productivity within our community, but it can also serve to distance us from projects outside it. When evaluating solutions to a problem, it can be easy to dismiss the ones that "aren't the Ember way" without too much consideration, meaning those projects in turn don't necessarily see much input from Ember folks, further widening the gap.
What Are We Missing Out On?
The Ember community makes up only a fraction of Web development as a whole, and that necessarily means a lot of the innovation going on is happening outside our figurative walls. If we write that off, it means we can miss out on new ideas and improvements happening outside our community. It also means we can easily wind up reinventing the wheel, spending time and energy on solving a problem ourselves rather than benefiting from something more robust that already exists.
Conversely, if we do develop something novel and valuable but it's only possible to use it in the context of an Ember project, that's a missed opportunity for the rest of the world. Given that one of the recurring themes for 2019 is broadening the Ember community, contributing useful framework-agnostic tools to the ecosystem could be a good way to draw others in.
How Do We Move Forward?
We're already heading in a positive direction! As mentioned above, the Octane programming model helps lower the barrier to entry for developers coming from other frameworks, and auto-import makes it much simpler to use arbitrary packages from npm in your Ember project.
Following through on the things people are bringing up again and again in #EmberJS2019 posts will get us even further along the way. Streamlining and modularizing Ember itself will further lower the barrier to entry for developers learning the framework for the first time, and broadening the community itself will naturally help erase the Us and Them mentality as the lines between in-group and out-group are no longer so clearly defined.
On the technical side, adopting Embroider will improve our interoperability with tooling not designed specifically for Ember. One of its goals is an explicit build phase after which all Ember conventions are "compiled out." Any processing that occurs after that can be performed by any tool that understands standards-compliant JavaScript. This has the potential to massively lower the barrier to experimentation with new ideas and techniques for bundling and distribution that were designed for generic Web projects.
You Mentioned Being Deliberate?
All of the things above will all naturally nudge us in the right direction, but I would urge that we as a community make an active effort to take advantage of our position as part of a larger ecosystem and encourage others to do the same.
Be thoughtful in how you frame the things you share. It can be super satisfying to {tweet|post|give a talk about} something cherry-picked that's trivial to do in Ember but {10x more code|4x slower|still an unsolved problem} in Framework X. It's great to celebrate the things our tool of choice is good at (and the people who worked hard to make it that way!), but not just as a way to score points. If you're going to engage in that way, do it in good faith and consider what tradeoffs led to the situation, rather than perpetuating the mentality that we're so good at something that they suck at.
Consider solutions that weren't custom-baked for Ember. Maybe you'll find something that works right out of the box, or maybe you can build a light wrapper around it. Either way, you might be able to save yourself both some time and some headaches by adopting something that's already battle tested.
Ask whether what you're building needs to be Ember-specific. If you do end up building something from scratch and you plan to share it publicly, consider whether it's something that applies uniquely to Ember projects. If not, maybe you can publish the core of your solution as a vanilla JS package and include the Ember-specific parts in an addon. Or, with auto-import gaining traction today and Embroider taking shape as the future, you may not need an addon at all!
A fantastic example of building something for Ember and then addressing the larger community is @samselikoff's Mirage project2. The ember-cli-mirage addon has become a part of the default development workflow for much of the Ember community, but the majority of the project could be equally useful to anyone writing a browser-based application that fetches data from a remote source. However, Mirage was conceived of and developed specifically for Ember projects, and for most of its lifetime, it was essentially impossible to use it in any other context.
Now, work is underway to extract a @miragejs/server package that's totally framework-agnostic. The ember-cli-mirage addon will be rewritten as a consumer of that package to continue to provide the Ember-specific bits that we're used to having, but the core system will be usable with any project, regardless of its choice of tools.
"Us" and "All of Us"
There is no Them, just bigger and bigger circles of Us. The Ember community isn't separate from the broader Web development one, and we shouldn't conceive of it that way. Our community is a part of that larger one, and cliché as it may be, everyone stands to benefit if we act accordingly and embrace it.
⤴️1. Please note that sociology is definitely not my area of expertise, and in discussing it I'm mostly matching my observations to things I read on Wikipedia and mentally going "oh hey, that totally fits!" 🙃
⤴️2. Mirage certainly isn't the only project to do this, but it's a super salient example right now. Chris Krycho's True Myth library and our own Milestones project are also examples of projects built this way.