Ember 2018 Roadmap RFC

Summary

This RFC sets the Ember 2018 Roadmap. This year’s goals are to:

• Improve communication and streamline decision-making, and empower new leaders.
• Finish the major initiatives that we’ve already started.
• Ship a new edition, Ember Octane, focused on performance and productivity.

Motivation

This document is a distillation of multiple sources:

1. The 2018 Community Survey.
2. Community #EmberJS2018 blog posts, authored in response to our call for posts.
3. Discussion on https://discuss.emberjs.com
4. Deliberations among the Ember core teams.

The goal of the RFC is to align the Ember community around a set of shared, achievable goals that balance the needs of existing users with the need to grow and support new use cases.

Detailed design

This year is primarily about finishing initiatives that we’ve already started, fine-tuning our communication channels, and getting the world excited about Ember.

• Improve communication and streamline decision-making. We will expand and refine the core team structure, to ensure decisions are made quickly, communication is clear, and users feel empowered to become contributors. We will invest in mentoring new leaders, and cross-pollinating knowledge between teams. As a community, we will share our excitement about Ember with the wider web development world.
• Finish what we started. We need to focus on stabilizing and polishing the work that we’ve already started in 2018. We will add extension points to allow popular new tools to be quickly adopted in Ember apps. We will standardize around ES modules and npm packages, better enabling the sharing of Ember tools with the wider JavaScript community.
• Ship Ember Octane. We will ship a new edition of Ember, emphasizing its modern productivity and performance. We will polish our compatibility with new JavaScript language features like native classes, decorators, and async functions. We will continue efforts like optional jQuery and treeshaking that reduce file size. We will overhaul the Ember homepage to align with Octane and tell the story of modern Ember.

To help us deliver a polished, cohesive experience, we will focus on two end-to-end, real world use cases. Having concrete use cases in mind helps us improve our marketing as well as prioritize feature development. In 2018, our two use cases are:

• Productivity apps. Ember’s historical strength: sophisticated, highly interactive apps that users spend a lot of time in, getting things done.
• Content apps, where pages are text-heavy and where the first load is critical. In performance-constrained environments, Ember’s strong conventions can help developers build faster apps by default.

Improve communication and streamline decision-making

Silence is the only thing that cause developers to lose trust in Ember. And overcommunication is the cure to silence. —Ryan Toronto and Sam Selikoff

Technical leadership seems to me to be about 10% technical brilliance and 90% clear communication. We have loads of technical brilliance; we need more communication! —Chris Krycho

Communication is well, not stellar. Newsletters do a great job at communicating what already happened, but future plans are largely unknown to public. —V. Lascik

The Core Team is in a unique position to add external-facing commentary on the framework's vision. Our RFC process and release posts are awesome, and they have done great things internally, so I would like to encourage Core to look outwards next. —Jen Weber

My hope is that Ember will continue to be an investment worth making. I see a growing, diverse community with lots of fresh faces as an essential part of that. —Matt McManus

Finding how and where I can help feels scattered. Issues do not receive effective labeling. This has translated into me not contributing to varying projects. —Eli Flanagan

What I’d wish for Ember’s 2018 Roadmap though is to find ways to lower the entry barriers for newcomers to get started in their attempt to advocate Ember and to be creative on how to encourage a sense of empowerment in the wider community regarding outreach efforts. —Jessica Jordan

My hope is that we will continue to hand off the baton of the community values to developers who are new to Ember. —Bill Heaton

A good idea would be to continue creating quests for small things like documentation, code-cleaning… And maybe add a place where this quest can be found —Benjamin Jegard

There has never been more time and energy going into Ember, but we’ve heard loud and clear that this momentum is not as visible as it needs to be. We are going to prioritize sharing work as it happens, making planning and status updates more discoverable, and making it easier for would-be contributors to get involved.

We also need to double down on making Ember as friendly and inclusive as possible, particularly for folks who have never participated in an open source project before. As we bring in new community members, we will make changes to ensure that individuals can have a meaningful impact, no matter what time zone they live in.

Lastly, we need to make sure that our core teams are not so bogged down that they become a bottleneck for decision-making. Core teams and strike teams decentralize planning, empower new contributors to take ownership of community initiatives, and help to build and strengthen relationships among community members. We will invest in improving the organization and structure of these teams this year.

To accomplish these goals, this year we will:

• Expand and refine our team structure, breaking up work and delegating it to strike teams or new core teams as appropriate.
• Move to discoverable communication tools, such as our Discourse forum, which is visible to search engines, and Discord chat, which doesn't lose history.
• Invest in mentoring. This includes direct mentorship relationships, as well as written guides like quest issues that are helpful even for people in different time zones or who have difficulty with spoken English.
• Track RFC implementation via GitHub issues, so it's clear what the next steps are after an RFC is merged.
• Automate communication and status updates. For example, we will improve the Statusboard to automatically pull from RFCs and RFC tracking issues.
• Document “best practices” for core teams, spreading knowledge about what works and what doesn’t for building an active community.
• Unify the RFC process to ensure a consistent experience across all of Ember's sub-projects.

Finish what we started

The last few years have seen the Ember team do a lot of really important exploratory work, including projects like Glimmer.js; and we have landed some of the initiatives we have started. But I think it’s fair to say that focus has not been our strong suit. It’s time for a year of shipping.—Chris Krycho

I think the goal of being able to just npm install or yarn install any package and having it "just work" should be high on the TODO list. —Andrew Callahan

When Yehuda Katz closed that RFC, I think a bit of that dream died, but at the same time I was happy. Not because it wasn't going to happen but because there was clear communication, finally. —Ilya Radchenko

I firmly believe that Ember needs to deliver all the great new features that are currently in flight before taking more to its plate. —Josemar Luedke

This year, we need a strong focus on shipping. Huge improvements to Ember have either already landed or are in the pipeline. We need to cross the finish line on these before moving on to new initiatives, however important or exciting they might seem.

“Done” doesn’t mean behind a feature flag on canary. Finishing what we started means ensuring that features are discoverable, on by default, and that the guides and other documentation have been revised to take them into account. It means making sure they work well with the entire Ember ecosystem so that new developers get a seamless experience.

This year, we are going to ship:

• Broccoli 2.0 in Ember CLI, as well as significant investment into Broccoli documentation, marketing and advocacy.
• Module Unification as the default file system layout.
• Glimmer Components as the default component API.
• Native JavaScript classes as the default object model.
• Native JavaScript modules, including:
• Exposing modules in the build pipeline and allowing addons to integrate tools like Parcel, Rollup or Webpack.
• Publishing Ember as npm packages.
• Importing npm packages into your Ember apps with zero additional configuration. (This was, far and away, the most-mentioned feature request in all of the #EmberJS2018 blog posts.)

Ember Octane

The homepage looks a bit outdated and does not a very compelling job at selling Ember to new users, IMHO. This needs to change. —Simon Ihmig

When you generate a project with ember new, you get a project that is almost “legacy” by standards of the wider JavaScript community. —Gaurav Munjal

Ember's custom object model isn't hard to learn, but it's a big reason people are turned off before learning why Ember is such a great choce. I'd like to see ES classes support finished and adopted in the Guides ASAP, followed by decorators. —Michael Kaiser-Nyman

ES6 syntax, the new file layout, new templating etc. — the new features will land in 3.x releases as non-breaking changes, but let’s prepare to show off the sum of all those amazing parts. Sell the vision, right now! A ‘relaunch’ of Ember in the minds of those who dismiss it. —Will Viles

Ember releases a new, stable version every six weeks. For existing users, this drumbeat of incremental improvement is easier to keep up with than splashy, big-bang releases.

However, for people not following Ember closely, it’s easy to miss the significant improvements that happen over time. As detailed in the forthcoming Ember Editions RFC (being worked on by Dave Wasmer), every year or so we will release a new edition of Ember, focused on a particular theme. The set of improvements related to that theme, taken together, mark a meaningful change to how people should think about Ember.

In 2018, we will release the first edition of Ember, called Ember Octane. Octane will focus on the themes of productivity and performance. We’ll talk about how Ember excels in performance-constrained environments, particularly on mobile devices, as well as the productivity benefits of modern JavaScript features like classes, decorators, and async functions when paired with Ember’s strong conventions and community.

This is also a good time for us to review the new application blueprint, to ensure that it is up-to-date with the latest Ember Octane idioms and includes the right set of addons to help new users achieve our goals of productivity and performance.

Ember Octane is about doing more with less. Not only does this make Ember simpler to learn, it makes the framework smaller and faster, too. These are some of the highlights of Ember Octane:

• No jQuery. Currently available as an optional feature, we will enable this by default.
• Svelte builds, where deprecated features are stripped out of framework code. We will get more aggressive about deprecating code that is not widely used.
• Native JavaScript classes perform better and require less code, and integrate better with tools like TypeScript and ESLint.
• Glimmer components offer a greatly simplified API and remove common slow paths.
• Incremental rendering and rehydration that keeps even low-end devices responsive as the application boots.
• Treeshaking to automatically remove code unused by the application.
• Eliminating the runloop from the programming model, replaced by async and await in tests.
• Stabilizing Ember Data by streamlining internals and providing more extension points for applications and addons to customize behavior.

The final timeline and feature set of Ember Octane will be determined by the core teams and are not set in stone in this RFC.

In keeping with our commitment to finishing what we’ve started, these are all features that are either finished or being implemented now. We should not plan for Octane to have any features that are not already close to being done today, so that we have adequate time to make sure they all work well together as part a cohesive programming model.

The process of releasing a new edition also gives us an opportunity to evaluate what it’s like to use Ember end-to-end. We will overhaul the Ember homepage, focusing on Ember Octane and how it helps solve targeted use cases.

This is also a good time to perform a holistic review of the guides, making sure that examples use the latest idioms and set new learners on a good path.

Non-goals

One of our most important goals this year is to focus on shipping. Focus means saying “no” to ideas that we really like.

• Significant work on Glimmer.js. We will instead focus on our efforts on incorporating the lessons of Glimmer.js into work that enables a smaller core in Ember.
• Further Glimmer VM optimizations. Glimmer performance is industry leading and not a bottleneck in most Ember.js apps. At this point, the Ember.js payload is the primary performance bottleneck, and we should turn our attention to enabling better performance there.
• Brand new language features in either Handlebars templates or Ember’s JavaScript files. There is already a full pipeline of features, such as Glimmer components, JavaScript classes with decorators, and module unification that we need to finish before starting any new major design.