Start Date: 2019-07-29 Heavily Revised: 2020-02-28 Relevant Team(s): All teams RFC PR: https://github.com/emberjs/rfcs/pull/519
The purpose of the Ember Roadmap process is to rally the community around a number of shared goals. This post documents those goals for 2020.
Since the Ember community cannot predict the future, we cannot be sure that we will achieve all of the individual items enumerated here. Instead, the purpose of this document is to give the community a common purpose to aspire towards.
This year our two headline priorities are:
- Polish the practical and conceptual details of Octane (tracked properties, Glimmer components, related tooling, accessibility, performance and payload improvements).
This document is a distillation of multiple sources:
- The 2019 Community Survey.
- Community #EmberJS2019 blog posts authored in response to our call for posts.
- Discussion on https://discuss.emberjs.com, Discord, Twitter, and other public venues.
- Deliberations among the Ember core teams.
- Your comments and feedback on the roadmap RFC itself.
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 users.
Now that Ember Octane has shipped, it’s time to turn our attention to new efforts in 2020. Our goal is to build on Octane's release and capitalize on that cutting-edge foundation.
- Invest in Octane. Octane's mental model and basic components are complete, but a number of practical and conceptual gaps remain. We will close these gaps with work on tooling, by deprecating classic APIs to simplify Ember for new users, and by introducing additional functionality where appropriate.
- Modernize our build system. This year we will prioritize improvements to the Ember application build pipeline, and to Ember itself, which will bring modern optimizations like tree shaking and code splitting to both new applications and existing codebases.
- Better a11y by default. We will better support assistive technologies via updates to the router. Additionally we will provide developers more tools for understanding and improving the accessibility of their Ember applications. Our goal is a great "out of the box" experience with Ember and assistive technologies.
- Share Octane outside our community. Octane's release put Ember in front of a lot of new eyes. We will continue that trend through 2020 by talking about Octane in front of new audiences.
Ember Octane put the framework on a strong footing by modernizing its most foundational APIs. Many teams are already productive using Octane, and from their experience have provided a torrent of real-world feedback. We will continue improving the developer experience (DX) of Octane throughout 2020.
Many of the rough edges in Octane aren't on the features themselves, but in the supporting tooling. The usefulness of stack traces from Glimmer, the ability to use TypeScript with Ember templates, how tracked properties and Glimmer components are reflected in the Ember Inspector, and the build speed of our application pipelines are all important parts of Octane's DX. We will invest in these areas of work.
For developers who are new to Ember, the presence of classic non-Octane APIs can be disorienting. We will look for creative solutions that make those features trivial for existing apps to continue using while also making them less expensive (in payload, performance, and mental model) for new adopters.
Finally there are some areas of Octane features which can still benefit from new feature work:
@trackedsystem, for example, limits the expression of state in an application to defined properties on an object. Real-world codebases often want to maintain state as a list or a map, and we can extend on the well-designed internals of Ember's reactivity model to support these cases.
- Modifiers provide a hook into the DOM rendering lifecycle, but Octane has no APIs for hooking into other lifecycles in the rendering and object system. We will create these APIs.
- We will continue a push to make Ember templates better analyzable at build time by introducing a strict-mode template and static imports.
- We will make it easier to build ergonomic, reusable components by shipping named blocks.
We will introduce new features in Ember which improve Octane in these and other areas.
Last year, we started work on Embroider, an overhaul of the Ember CLI compilation pipeline. This year, we will put the finishing touches on Embroider and start migrating the Ember ecosystem to this modernized build.
This new approach, through its foundation on common packaging libraries, will also unlock new build time optimizations. These optimizations, like tree-shaking and route-based code-splitting, will allow Embroider to produce smaller asset payloads.
Additionally, we will introduce a system into Ember which allows apps to drop framework code supporting deprecated features unused by an app. This will result in smaller vendor assets for applications which don't rely on deprecated features. For example, a modern Octane application may not require
Ember.Component, and can benefit from having the code supporting that API being dropped at build time.
Finally, we will make sure this modernization effort provides benefits to existing applications. If a team has been steadily upgrading their app for years now, they won't need to rewrite it to get the benefits of a modern build packager.
Ember applications should be accessible to everyone. Unfortunately, even seemingly small mistakes can make your app difficult or impossible to use with assistive technology like screen readers. We will do more to improve the out-of-the-box accessibility of Ember applications, and provide tools to help applications stay accessible as they grow.
- Fix router accessibility so that page navigation is correctly announced by screen readers, without needing a third-party addon.
- Incorporate accessibility checks into the built-in test helpers.
- Engage with standards bodies to help fill the gaps in existing web accessibility APIs.
To contribute to this effort see RFC Issue 595 which coordinates the Ember A11y Strike Team.
There are more people building web applications than ever, and Ember must adapt to their changing needs and expectations in order to stay relevant. Octane better aligns Ember's API with what new users expect from a modern framework. We need to take advantage of that change.
We will continue to make Octane more attractive to new users with a new documentation approach, more effective website, and with clearer communication about the Glimmer.js project.
Making Ember more attractive to new users doesn't mean compromising on what has made the framework so very successful for existing codebases and teams.
The most basic value of the Ember project is that we solve problems together. While we intend to grow the number of framework users and modernize the framework in many ways, we won't optimize for growth at the expense of our existing community. Instead, we will collaborate on solutions that come with a curated adoption story.
By sharing common solutions to common problems with other communities we not only make Ember more approachable, we also benefit from the opportunity to exchange more ideas. Everyone wins.