Ember 2020 Roadmap RFC

text/000-2018-2019-roadmap.md

@@ -0,0 +1,88 @@
+- Start Date: 2019-07-29
+- Relevant Team(s): All teams
+- RFC PR: (after opening the RFC PR, update this with a link to it and update the file name)
+- Tracking: 
+
+# Ember 2019-2020 Roadmap
+
+## Summary
+
+This RFC sets the Ember 2019-2020 Roadmap. This year, our two priorities are:
+
+- Further reducing the size and conceptual complexity of the framework.
+- Accelerating ecosystem growth and improving ease of adoption.
+
+## Motivation
+
+This document is a distillation of multiple sources:
+
+1. The 2019 Community Survey.
+2. Community #EmberJS2019 blog posts, authored in response to our call for posts.
+3. Discussion on https://discuss.emberjs.com, Discord, Twitter, and other public venues.
+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 users.
+
+## Detailed design
+
+Now that all of Ember Octane’s features are code complete, it’s time to turn our attention to what we’ll focus on over the next year.
+
+In this roadmap, our goal is to build on last year’s momentum and capitalize on the cutting-edge foundation we laid with Ember Octane.
+
+- **Continue simplifying Ember.** With many new APIs introduced in Octane, our focus this year should be removing features that feel out of date. The overall API surface area of Ember will shrink substantially, making it smaller, faster, and more approachable to new learners.
+- **Modernize our build system.** This year, we will put the finishing touches on Embroider and make it the default build pipeline for new applications, unlocking optimizations like tree-shaking and route-based code splitting.
+- **Better a11y by default**. We will fix the router to work out-of-the-box with assistive technologies, and give developers more tools for understanding and improving the accessibility of their Ember applications.
+- **Optimize for growth.** A feeling of momentum is critical for keeping the Ember community healthy. We will double down on evangelizing Ember Octane and making Ember approachable to a new generation of web developers.
+
+### Continue simplifying Ember
+
+Ember Octane put us on a strong footing, modernizing the most foundational APIs in Ember. We will build on that foundation to dramatically simplify the framework, **reducing the overall number of concepts** so that Ember is easier to learn, use, and debug.
+
+We will **extract or deprecate functionality that is no longer widely needed**. With `get()` and `set()` mostly gone, so goes the need for many Ember-specific utility functions. Some utilities can be moved into optional packages for those who need them, while others may be better replaced by libraries like [Lodash](https://lodash.com/).
+
+Candidates for deprecation or extraction include:
+
+- **Object utilities** such as `isBlank`, `compare`, `trySet`, etc.
+- **String utilities** such as `camelize` and `dasherize`.
+- **Computed property macros** such as `alias`, `mapBy`, `notEmpty`, etc.
+- **Legacy object model features** such as observers, `setProperties`, `incrementProperty`, etc.
+
+Perhaps the longest-awaited simplification is **eliminating controllers** from the Ember programming model, which we will do this year. This will require us to find a new home for query parameters.
+
+Building on the simplicity of Glimmer components, we’ll also implement **template imports**, which make it explicit which helper or component is being invoked, and **named blocks**, which make it even easier to build ergonomic, reusable components.
+
+Lastly, we’ll **simplify and modernize Ember Data,** including:
+
+- **Easier on-ramp for new users** by eliminating the need for adapters and serializers for simple use cases based on `fetch()`.
+- **Increased velocity and stability** through improved, modularized internals.
+- **More flexibility** when overriding built-in behavior, by exposing low-level primitives as public API.
+
+### Modernize our build system
+
+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.
+
+By using standard JavaScript modules, Embroider integrates with popular packagers like [webpack](https://webpack.js.org/) and [r](https://rollupjs.org/guide/en/)[ollup](https://rollupjs.org/guide/en/), allowing us to **ship Ember itself as npm packages in the** `**@ember**` **namespace**. 
+
+These packagers also unlock build time optimizations like **tree-shaking,** and allow Embroider to produce smaller payloads with **route-based code-splitting.** Most importantly, they break down any remaining barriers between Ember and the rest of the JavaScript ecosystem.
+
+### Better a11y by default
+
+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 for helping applications stay accessible as they grow.
+
+- **Fix router accessibility** so that page navigations are correctly announced by screen readers, without needing a third-party addon.
+- Include **more a11y lint rules** to catch common accessibility mistakes.
+- **Document accessibility best practices** and treat accessibility as a first-class concern, as we do with automated testing.
+- Incorporate **accessibility checks** into the built-in test helpers.
+- **Engage with standards bodies** to help fill the gaps in existing web accessibility APIs.
+
+### Optimize for growth
+
+There are more people building web applications than ever, and Ember must adapt to their changing needs and expectations in order to stay relevant.
+
+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.
+
+It’s critical that, when they do, Ember Octane offers a polished experience. We’ll continue improving guides and API documentation based on community feedback. As a community, we need to prioritize bugs that seem small but that make a bad first impression for people trying Ember for the first time.
+
+Lastly, people often tell us that adopting Ember feels like an all-or-nothing decision. We need a way to give developers a preview of Ember’s productivity, even if they’re not ready to jump in feet first.
+
+This year, **we will bring Glimmer.js components to everyone**, giving the wider JavaScript community a taste of the fun of Ember Octane (even if it happens to be in a React app using webpack!).