@yarnpkg PnP is a fantastic way to reclaim some/a lot of disk space. I started some work last year to support it in Ember CLI, but couldn't finish it in time. We should revisit this!

I think we should treat learning as important as the technical ideas that distinguish ember.js. [...] My fabulous colleagues have often asked spot-on, difficult questions about the guide's admonitions to do something a particular way. I too often resort to shallow "that is just the way it is" answers.

[With Ember Octane] it's time for us to focus on how we structure and bind and package those modules, both at the framework and application levels.

Ember needs a way for a component to have direct knowledge of its children, [...] clearer about where they want to end up with the file system layout, [...] spread ...attributes on multiple elements, [...] and public API and get a full suite of documentation (for AST transforms).

I see a lot of work around but it's not written in roadmap anywhere. [...] it will be great to have kinda "likes" for non important features, to prioritize them.

My wishes for Ember (in 2019) is to slim down the framework is to throw old ballast over board to improve learning, developer ergonomics and align more with the javascript ecosystem.

The Community as a whole must remember that each and every single one of us are the only ones who will excite others about using Ember. We are the only ones who can pique curiosity of others.

The Octane edition will be great for performance and developer ergonomics, but it doesn’t fundamentally bolster (or change) the selling points of Ember. I think we need to aggressively reduce the API surface area at every level from core classes to CLI tooling, converge into the JS ecosystem and “the platform”, and make the application’s inner workings more explicit by both providing low level primitives and using them in an obvious way.

I would like us to address some of the long standing issues and missing features, as well as bring in some of the nice things from the JSX world, while staying true to what makes templates feel so productive in Ember today.

The Ember community makes up only a fraction of Web development as a whole, and that necessarily means a lot of the innovation going on is happening outside our figurative walls. [...] Conversely, if we do develop something novel and valuable but it's only possible to use it in the context of an Ember project, that's a missed opportunity for the rest of the world.

Ember has fallen off the radar. Pretty much any article about front-end talks about React/Angular/Vue and that's the end of it. They are taking such a big market share that Ember will struggle despite its technical merits. [...] I noticed several Ember developers going out in the wild to talk about Ember. This is great. We need more and better marketing and PR.

Testing has always been a strength of Ember. [...] Yet, it is still too hard for some organizations to start testing. [...] It is important, that as we go forward as a community, we don’t give up our lead in this area and address these pain points that continue to make testing difficult.

A special section in the guides on integrating Ember.js into a classic app could help interested developers become comfortable with both the technical process and with the idea that the Ember.js community supported this use case.

[O]n-boarding new and fresh minds from a different background of frameworks into teams that use Ember, has been quite a challenge. Not because the framework is difficult to learn, but the dots around the documentation need a bit more connectivity.