My hopes for Ember in 2018

I’ve spent the last three years of my career working with Ember in one way or another, most of the time as part of my full-time job. I love this framework. In fact, Ember is the reason I moved out of the data science world and into web development. After hearing numerous talks from Tom and Yehuda from 2014-2015 period, I got the sense that the Ember core team was playing on a different level than the rest of front-end world. There were so many truly sound ideas regarding how software development ought to work, how tradeoffs between innovation and stability are made, and what it means to truly harness the power of the web as a platform. In my time with Ember since hearing those initial talks, I’ve seen just how committed the Ember community is to those principles, and am consistently impressed by the framework, its addons, and the community of people behind it all.

That said, it’s 2018, and we’re doing this (very good) Roadmap blog thing, so here goes:

There are many things I’d like to see from Ember in 2018. Chief among them are:

All of those bullet points have been written about in great detail in some other fantastic blog posts, though. (Shout out to Chris Krycho’s litany of blog posts, starting here). So rather than echo the sentiments expressed elsewhere, I’d like to talk about another hope I have for Ember in 2018: I want the Ember community to kill its darlings.

Normative and nowhere to go #

One of the few pieces of academic writing I remember from my grad school days is an article entitled “Normative and Nowhere To Go” (source) in which the author laments the state of discourse in the legal profession, particularly regarding the fact that “norms” like “Justice”, “Oppression”, “Choice”, “Evil”, and other capital-letter concepts ceased being discussed as concepts unto themselves, but had instead become standard salvos in a rhetorical “language game” played by insiders in the legal field. A back-and-forth dance of loaded terms that often served only to impede the actual discussion at hand. To paraphrase the author, if I call a thing “justice”, and we all agree that “justice” is good, then it follows that my thing must be good. If you disagree, you must first win an argument about the validity or desirability of “justice” before you have a leg to stand on regarding your original thesis.

In other words, in the legal discourse, the commonly held norms of the legal profession had gone from being intrinsically valuable and convincing concepts to being tools for rhetoric and, in some cases, manipulation and self-deceit. The reason I remember this article even years later was the takeaway that (as the title alludes to) in a community where values can no longer be interrogated on their own merit, useful discourse can be difficult because Big Picture conversations are left with nowhere to go.

What does this even have to do with Ember? #

Let’s talk about some commonly expressed sentiments in the Ember community:

And finally

I’d be shocked if we haven’t all heard each of these concepts expressed in one way or another (or in some cases, verbatim), often in the same breath as an explanation of why using Ember is a Good Idea™.

Here’s the thing:

I know how to read between the lines on all of those.
I know each of those statements ring both true and hollow at the same time.
I understand the nuance involved in talking about something as long-lived and accomplished and flawed as this very excellent Javascript framework that we all know and love.

And so do you, Ember developer. We all know what these things mean, because we’ve already been sold on Ember, we’ve seen the amazing things it can do. We’ve also experienced its pain points and deemed its tradeoffs favorable.

But…the rest of the Javascript world hasn’t, and honestly they don’t care, and we need to stop telling ourselves that they do. If the Javascript community at large could be swayed by a set of platitudes, they’d already be Ember users. “Stability without Stagnation” is a so-so marketing slogan that is also a great development practice, but it’s a tough pill to swallow if you haven’t already experienced it as an Ember developer.

When Ember began, the idea of “web applications” was brand new. The idea that front-end development could be a difficult, yet rewarding, technical challenge that also happened to be very lucrative was laughable. The Javascript community lacked the language to even talk about web apps in the way Ember envisioned them, and as a result we needed heuristics. Shortcuts to encapsulate the ambitious ideas that Ember brought to the table in a way that made them accessible.

None of that is true anymore. The world is sold on web apps, the JS community has moved on past jQuery soup and re-invented the wheel a thousand times in pursuit of a better mousetrap because, honestly, web applications make money. There’s also a whole host of other, less directly capitalist reasons why web apps are good and why they web as a platform is a thing worth embracing, but the primary equation here is how well can you balance the need to ship with the desire to not ship garbage?

Which, conveniently, is literally Ember’s ACTUAL greatest strength. The community is fantastic, it’s an astonishingly well-run OSS project, it has a dope logo (shoutout to Tomster and Zoey), and all of that is going to be appreciated by people after we convince them that, dollars to donuts, Ember is far and away their best bet for shipping software on the web that’s tested, supported, and actually has a half-decent chance of being maintainable.

As we discuss the future of Ember we need to recognize that without learning how to talk about Ember to the rest of the Javascript world, having any future becomes less and less of a guarantee. Ember has a lot to offer to other Javascript communities, as well as a lot to learn. The more we can leave our biases and platitudes behind, the easier it becomes to share ideas and technologies “across the aisle”, to attract new and diverse talent, and, hopefully, to share this thing we all love with a whole new audience.