

























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:
This document was started in fall 2019. It is a distillation of multiple sources:
The goal of the roadmap 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.
Ember Octane put the framework on a strong footing by modernizing its most foundational APIs. 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:
@tracked system, 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.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.
Embroider integrates Ember CLI with popular packagers like webpack and rollup. It allows Ember apps to trivially import from any dependency published as standard JavaScript modules, and will unblock shipping Ember itself as npm packages in the @ember namespace.
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.
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.
This year, we’ll share with the world how Ember Octane is modern, productive, and fun. Through blog posts, videos, social media, meetups, and conferences, we will share our knowledge and experiences with the wider JavaScript community and encourage them to give Octane a try.
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.
Because we understand and value the power of collaboration, we know we must lower barriers, technical and non-technical, which not only make new users hesitate to adopt Ember but also discourage Ember developers from participating the greater JavaScript community.
A great example of our progress in this is Octane's embrace of native JavaScript classes: A JavaScript developer starting out with Ember today isn't immediately forced to learn a new, Ember-specific class API before they can get to writing code. On the other hand, a developer who starts off with Ember can also contribute to most OSS JavaScript projects without needing to first un-learn the Ember class system.
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.
With our efforts to flesh out Octane, improve the build system and align it with the rest of the JavaScript community, raise the baseline support for accessible applications, and to better communicate in 2020 we will lower barriers to adoption of Ember, but also to our own collaboration with the greater JavaScript project.
Want to get involved? Visit our community page and feel free to join us on Discord (chat) or Discourse (forum discussion).
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。