Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ember 2020 Roadmap RFC #519

Merged
merged 8 commits into from May 1, 2020
Merged

Ember 2020 Roadmap RFC #519

merged 8 commits into from May 1, 2020

Conversation

@tomdale
Copy link
Member

@tomdale tomdale commented Jul 29, 2019

Original description 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.

This RFC sets the Ember 2020 Roadmap.


Candidates for deprecation or extraction include:

- **Object utilities** such as `isBlank`, `compare`, `trySet`, etc.
Copy link
Contributor

@efx efx Jul 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Linking to @elwayman02's thoughts here: #516

Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I intend to follow this up with an RFC once we've had a bit more discussion to make sure I'm not missing anything.

Loading

Copy link
Contributor

@efx efx Jul 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Linking as well to @snewcomer's older, similar proposal: #334

Loading

@Gaurav0
Copy link
Contributor

@Gaurav0 Gaurav0 commented Jul 29, 2019

To point out the elephant in the room, there is no mention of another edition or of Ember 4.0

Loading

@rwjblue
Copy link
Member

@rwjblue rwjblue commented Jul 29, 2019

there is no mention of another edition or of Ember 4.0

Indeed, I do not believe that is a mistake. If we happen to do 4.0 in this cycle, I personally would be fine with it but doign a major bump itself isn't an objective of ours.

RE: Editions, I don't think we ever expected to have an Edition per year or on any specific cadence. Editions are a tool to allow us to have a coherence point across the ecosystem after having a number of divergent features, this roadmap doesn't really include features that are incoherent and therefore doesn't benefit from an edition.

Loading

@MelSumner
Copy link
Contributor

@MelSumner MelSumner commented Jul 29, 2019

To point out the elephant in the room, there is no mention of another edition or of Ember 4.0

Another edition so quickly after Octane would, I think, be equal parts defeating the point of an edition and monumentally exhausting. It's taken a ton of work from so many people just to see the Octane finish line.

Loading

@elwayman02
Copy link

@elwayman02 elwayman02 commented Jul 29, 2019

Thirding Melanie & Rob's thoughts - I think we'd achieve "Edition Fatigue" within the community very quickly if we started churning out editions every time we shipped the last one, just for the sake of having an edition. Octane was needed because there were so many initiatives coming together to really change how we thought about and worked with Ember, so it was necessary from a messaging standpoint to wrap it up into an Edition bow. Not every major initiative needs to be tied in like this, and there should be a marketing purpose for the community when we decide to create an edition imo.

Loading

@MelSumner
Copy link
Contributor

@MelSumner MelSumner commented Jul 29, 2019

Engage with standards bodies to help fill the gaps in existing web accessibility APIs.

I'm really excited about this one. I think we have a good idea of the things we need from A11y APIs and it will be great to bring useful things to the entire universe of web development.

Loading

text/000-2018-2019-roadmap.md Outdated Show resolved Hide resolved
Loading
@barelyknown
Copy link

@barelyknown barelyknown commented Jul 30, 2019

Before I mention what I think is missing, there's a lot that's great:

  1. Reduced Ember surface area
  2. Further integration with the broader JS ecosystem
  3. Build system enhancements for optimized performance
  4. Accessibility-friendly defaults
  5. Clear communication and a great experience for all developers

But... I miss the focus on ambitious web applications.

All the attention paid to making the onramp to Ember more friendly and modern is important, and I'm for it! But, the best that Ember can ever do in those areas is be good enough; there will always be simpler frameworks that are easier to get started with. We need a steady stream of new entrants into our community to prevent us from shriveling away, and we need to aim higher, not lower to stay vibrant.

Specifically, the types of goals that would feel ambitious to me are:

  1. 🏆 A more robust vision for ember-data (probably built on Orbit.js) to enable optimistic UI patterns, connection durability, client-first development, undo/redo support, etc
  2. Enhanced hybrid app story, with more first class support for and documentation related to corber.io
  3. Formal embrace of ember-animated in guides, documentation, and marketing to push motion as a first class concern
  4. Maintained focus on FastBoot and the ambitious strategies that it enables (e.g. static first)

I ❤️ Ember, and I'm happy everyday that we bet our company on it. I just fear stagnation, especially in pursuit of goals that are unattainable. Plus, I feel like I've seen the 🌟 future 🌟 with Orbit.js, and so maybe I'm just wishing for a more perfect union.

Loading

@tleperou
Copy link

@tleperou tleperou commented Jul 30, 2019

That sounds great.

Optimize for growth sounds a key here, specially to get more contributors.

@barelyknown you have a good point

Maintained focus on FastBoot and the ambitious strategies that it enables (e.g. static first)

The static first class is an important element of the Optimize for growth. To reach the new generation of server side rendering web sites' developers, we have to get rid of the (arguable) significant learning curve.

Like @MelSumner, I feel really excited about the Better a11y by default. There are plenty of - required - improvements on the Web. And plenty of room for Ember to provide great solutions.

Loading

@willviles
Copy link

@willviles willviles commented Jul 30, 2019

@barelyknown I’d argue that your goals 2, 3 & 4 are solved by ‘clear communication’, as are a lot of concerns around increasing adoption of the framework and accelerating growth.

My colleagues at work (React & Angular developers) are very interested to learn Ember after I personally walked them through some Octane features, but are at a total loss as to how to start their own personal learning of modern Ember.

I think the learning team do an amazing job for keeping those already invested in the framework in the loop. However, the longer Ember goes without a well rationalized and designed marketing & docs site, the longer the framework will stagnate.

Far from doubting the ability of anyone in the Ember community, I’m generally sceptical whether open source contributions alone can produce and maintain marketing & docs in a timely and satisfactory manner. Even after reducing the surface area of the Ember API, it is simply a mammoth undertaking to communicate all the intricacies of this framework.

Whilst Angular and React have full time Google and Facebook teams working on documentation & marketing, Ember’s best learning tools are the fruits of the full time focus of the awesome guys at EmberMap. Unfortunately most of the essential resources are behind a paywall.

My colleague said to me after getting increasingly frustrated with trying to learn modern Ember from a handful of blog posts and merged RFCs, “Why don’t LinkedIn just hire some people to sort this out?” I gave him the stock, “Ember’s an open source community” response, but essentially I agreed.

I’d be interested to know what the core & learning teams think about pitching for funding from the framework’s most invested companies, in order to engage a full time team to be the mouthpiece of modern Ember.

  • Is it too against the core principles of the framework?
  • Would people agree that growth could be significantly accelerated by having a full time Ember team?
  • Would people agree that the Ember marketing & docs may be of better quality if a full time team were working on it?
  • Or does everyone believe Ember can be communicated to it’s best capabilities through open source contributions alone?

Loading

@tleperou
Copy link

@tleperou tleperou commented Jul 30, 2019

@willviles, you've just brought it into focus. Personally, I share your point of view.

Let me know if I am wrong, but none of Emberistas, particularly core members, expect Ember to become the mainstream. However, more adoption means more potential contributions.

The Website of EmberJS - or an official commercial representative of the Ember Open Source community - should engage a stronger marketing approach to reach the real potential of Ember. Would sponsors be enough for supporting a fulltime team? 🤔

Loading

@mehulkar
Copy link
Contributor

@mehulkar mehulkar commented Jul 30, 2019

This is great! I’m looking forward to the marketing / branding push, as well as the focus on router/controllers and the default Octane blueprint.

One additional thing that I REALLY want to see is more on SSR. I see mentions of fastboot here and there (e.g. modifiers), but I think it’s time to make it a first class concern as well. @tomdale said in a recent talk that Ember for the next 10 years is about making web apps for the world, and I think web perf (which includes Fastboot and other SSR techniques) can/should play a role in that goal.

Loading

@pzuraq
Copy link
Contributor

@pzuraq pzuraq commented Jul 30, 2019

@barelyknown I definitely agree that Ember needs to continue to be ambitious in the future if we're going to stand out and gain interest from the larger community. I also agree with all of the potential features you've listed, though I would like to say that the Ember Data team has been quietly iterating toward a newer, much more well rationalized future for Data that I'm personally really excited about (there have been several merged RFCs recently you can check out for more details!)

The thing is, the goal in slimming down the framework isn't just about chasing the same targets as other frameworks. Yes, we want to get smaller in part because it's important for performance, etc. However, it's also important from a maintenance perspective.

There are many bugs and loads of overhead that come with having to support the legacy object model, the utility methods, CPs and CP macros, observers, event listeners, etc. It's also a major time sink for documentation efforts, and it causes confusion in the ecosystem to have two ways of doing things. The build side of things has a similar issue - we're maintaining our entire build pipeline currently, one that grew organically over time and has quite a few pain points and issues. It's served us well over the years, but now it's more of a drag on our ecosystem than a benefit.

Embroider, template imports, and slimming down the framework are, to me, just as much about freeing up our plates and getting time back as they are about simplifying the framework and making it smaller, physically. I definitely want to get back to building new, ambitious features, and I'm confident that by this time next year that's exactly what we'll be planning for 😄 personally, I'd like to take the time in the post-Octane period to cleanup as much debt as possible, to prepare ourselves for that. I think this roadmap sets us up to be successful in that regard.

One final note: I do think that we've shipped some pretty ambitious features in Octane. In particular, tracked properties are a game changer, and I still haven't found much that's similar in other ecosystems. We definitely can do more, but I think we should also recognize what we've accomplished as a community, and also take a bit of a breather (and clean up some legacy debt!)

Loading

@barelyknown
Copy link

@barelyknown barelyknown commented Jul 30, 2019

@pzuraq Yes, I totally agree that the features bundled up in Octane are excellent and exciting. 💯

I also totally agree that slimming things down in the wake of Octane is smart, and will free up valuable time and attention to push things forward. 💯

As it relates to Ember Data, I agree that there has been huge progress made over the years. Our company has built excellent features that heavily depend on Ember Data, and as it has improved, our app has improved. But... I don’t think that I agree that Ember Data represents an ambitious enough future (at least not as I understand it). I put the 🏆 in my comment above, because this is really the punchline to me. When I look at what’s possible with Orbit.js (and make smaller apps to explore those possibilities), it’s so far beyond what Ember Data is trying to do that it makes me wonder if we’re shooting too low.

I’ve tried to be careful to strike the right tone with my comments. I’m tremendously grateful to the community for what its built. That said, this is a roadmap RFC, and so it seems the time to bring these types of points up.

Loading

@elwayman02
Copy link

@elwayman02 elwayman02 commented Jul 30, 2019

I would suggest that diving into the details of Orbit vs M3 vs whatever for the future of Ember-Data is a good topic for an issue thread on the E-D repo. I think you're both in agreement that E-D should be more ambitious in the future than it has been historically, and the only disagreement is whether the current direction is that. In order for you both to understand what the other is talking about would require going into a lot more detail than is necessary for this RFC. It's an important discussion, however, so I hope that it continues!

Loading

@MelSumner
Copy link
Contributor

@MelSumner MelSumner commented Jul 30, 2019

That said, this is a roadmap RFC, and so it seems the time to bring these types of points up.

@barelyknown yes, definitely!! I also think it could be something that we explore and "unofficially" work on, maybe even submit CFP to talk at conferences about- it's good to have future-looking ideas and keep ourselves moving forward.

All the attention paid to making the onramp to Ember more friendly and modern is important, and I'm for it! But, the best that Ember can ever do in those areas is be good enough; there will always be simpler frameworks that are easier to get started with. We need a steady stream of new entrants into our community to prevent us from shriveling away, and we need to aim higher, not lower to stay vibrant.

I am 100% in agreement with this, so so much.

Loading

- **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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if dynamic query params is something that could be explored as part of these changes!

Loading

Copy link
Contributor

@mehulkar mehulkar Aug 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dynamic route segments also! e.g. handling both foo.com/posts/:seo/:id and foo.com/posts/:id with the same route handler.

Loading

@tschoartschi
Copy link

@tschoartschi tschoartschi commented Jul 31, 2019

I really like the roadmap RFC 🙂thanks for putting it together. I also read a lot of #EmberJS2019 blog posts and I think the RFC summarizes it very well.

🏃‍♀Accelerating ecosystem growth

I want to mention three things concerning the "Accelerating ecosystem growth" goal:

🧳Ember-Data

We started a new Ember.js project this year in March. Our team consisted of people with no background of Ember.js, some had experience in React and Angular and some come from Android development. Despite Ember-Data is a great piece of software it was one of the main pain points for our newcomers (we do not use controllers, we just create top-level components, so we had no problems in this space).

The problem for them was often to distinguish were Ember.js ends and where Ember-Data starts. Also, it was hard for them to grasp what's the role of Ember-Data in the Ember-Ecosystem. I often got questions like: "Is Ember-Data the Redux of Ember" etc. These problems with the mental model made it really hard for them to feel comfortable.

Furthermore, the part of the guides speaking about Ember-Data is very small. This is bad because Ember-Data does a lot and after reading the guides it does not seem like it. Another pain point was that there are a lot of issues (from March until now, we had to work around many things). Relations are very tricky and better guides about this topic would improve onboarding a lot.

We use the DS.RESTSerializer and we encountered some rough edges especially with links within the payload.

I know this is a roadmap RFC for Ember.js but since Ember-Data comes as default with ember init I think the Ember-Data experience should be as great as the Ember.js one. I'm sure 90% of the problems can be fixed with more and better guides, examples and "recipes".

👩🏼‍🔬 Innovations

With Octane we modernized the look & feel for developers a lot. DX improved drastically. Ember feels now like a thin layer above regular JavaScript. Octane also laid out the ground for new innovations and I think we need to show off some innovations other frameworks do not have. I think on things like, binary templates, render engine as WASM. Personally, I would also love to see an integration of css-blocks.

💪 Types and TypeScript

For our newest Ember.js project we use TypeScript and it works very well. Especially for our newcomers, the features TypeScript provides helped them a lot to improve their understanding of the framework and helped them get up to speed quickly. But across the ecosystem, we miss a lot of Types. Therefore I believe that improving the typeing story should be an ecosystem goal where all the addon-authors, core-team-member and Ember.js users work together. It should be easy to contribute type-definitions. Furthermore, it would be great to see things like typed templates happening.

💡Other thoughts

Since we are Glimmer.js users we would like to have a statement what the role of Glimmer.js will be in the Ember ecosystem in 2019. This is very important for us, especially because new projects are around the corner and these projects will need something like Glimmer.js. Without knowing anything about the plans it's hard for us to argue why we are not using things like (P)React or Vue.

Last year we had a section about the none-goals. I think it would be good to have such a section again so that everybody has an objective view on what will happen and whatnot.

Loading

@pzuraq
Copy link
Contributor

@pzuraq pzuraq commented Jul 31, 2019

@barelyknown

But... I don’t think that I agree that Ember Data represents an ambitious enough future (at least not as I understand it)

I think you may be pleasantly surprised. The data team's plans are quite ambitious, as far as I understand them, though these things do take time, and there's a lot of work to be done still, so I'm not sure everything will be landing in this year's roadmap. I actually expect 2020-2021 to be a big year for Ember Data 😄

@tschoartschi

The problem for them was often to distinguish were Ember.js ends and where Ember-Data starts.

This is actually a pretty big part of the reason why it's taking a while to ship things in Data, there's a lot of debt, and it's tied pretty deeply to Ember's own implementation details. Separating the two out is a huge part of moving forward, with larger refactors to follow.

Loading

@bfitch
Copy link

@bfitch bfitch commented Aug 2, 2019

@MelSumner @barelyknown

All the attention paid to making the onramp to Ember more friendly and modern is important, and I'm for it! But, the best that Ember can ever do in those areas is be good enough; there will always be simpler frameworks that are easier to get started with. We need a steady stream of new entrants into our community to prevent us from shriveling away, and we need to aim higher, not lower to stay vibrant.

I am 100% in agreement with this, so so much.

This assumes that Ember's current learning curve/complexity is inherent or unavoidable to the problem space, but as this RFC shows, it's really not! Controllers, the build pipeline, ember-data, and the Ember object model are all being replaced with conceptually simpler and more powerful alternatives.

I love Octane and this RFC specifically because they're all about honing in on and removing those vestiges of accidental complexity that have accreted over Ember's long history. The Octane programming model is as clear and rationalized as any other framework out there at the moment. Combined with Embroider and better JS ecosystem integration, we have no reason to settle for Ember simply being "good enough" here.

There's no zero-sum game between (1) simplifying Ember and (2) tackling ambitious new features, in fact, they go together and reinforce one another. Pruning and simplifying APIs and the programming model means: smaller learning curve, less maintenance burden, easier communication, and more time for ambitious features! Win win.

Loading

@dgeb
Copy link
Member

@dgeb dgeb commented Aug 2, 2019

As both the creator of Orbit.js and a member of the Ember Data team, I'd like to echo what @pzuraq has said about the ambitious plans for Ember Data. I've been working for a very long time to bring the benefits of Orbit to Ember Data. This has involved working with the rest of the team on refactoring and slimming down internals, as well as defining new public interfaces within Ember Data. My goal all along has been to be able to "plug" Orbit into the new interfaces being defined within Ember Data, which should unlock quite a few of Orbit's capabilities seemingly "for free" (well, to the developer, anyway). I outlined this vision in my EmberConf 2018 talk.

It's fair to say that we (the Ember Data team) haven't been heavily selling this ambitious future. We've talked a lot about the process to date, without focusing as much on the potential benefits. Part of the reason is that we still have a little ways to go and want to see everything working well together before making any pronouncements. Another reason is that Orbit compatibility isn't our singular goal. On the other end of the spectrum, we want Ember Data to support simple use cases, such as a basic repository for fetch results. We also want to support libraries, like ember-m3, that take a different view of data normalization. Ember Data will soon be a leaner, more flexible, and more "pluggable" library than it is today. It will be a "big tent" that supports a wide spectrum of use cases.

Last but not least, I'm really energized by the enthusiasm for Orbit and its ambitious goals shown by @barelyknown and others. At times, working on Orbit has felt like a walk in the desert, but it's gratifying to see a lot of work come to fruition for my projects as well as for others. I suppose we shouldn't dive too deep in this discussion thread, but if you are curious about Orbit and/or ember-orbit, please feel free to reach out to me in the #topic-data-management channel in discord or in Orbit's gitter channel. And if you want to reach out to help accelerate the work to bridge these two worlds, reach out in #dev-ember-data on discord.

Loading

@@ -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)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reminder to add the link here! 🙏

Loading


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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where they exist, can we link to the RFCs for features like template imports throughout this document? I imagine that people will find it very useful to know what has already been planned, particularly if they are not already aware what these terms mean in a practical sense. That will help people reviewing the RFC better understand how the planned direction will manifest!

Loading


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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This, to me, is one of the most important pieces of this roadmap, and I hope people do not gloss over it. I can't remember the last time I attended a conference/meetup that was not specifically focused on Ember and saw someone giving a talk about Ember. We need to make a concerted effort at outreach, and I hope that someone will be writing a follow-up RFC detailing exactly how we will accomplish this rather than simply jumping straight from this roadmap into "executing" at this broad-stroke level.

Loading

@unibum
Copy link

@unibum unibum commented Aug 4, 2019

Disclaimer, I’m not a coder/developer and being following Ember pre 1.0.

Has anyone considered an Ember Infrastructure team to attract more developers (and start-ups)? Through the lens of a cash strapped start-up as an example, I don’t really want my self-taught javascript/front end guy deploying and configuring any other software in any environment let alone my production webserver, Db and every other system needed in-between. Ember has a number of great things that I simply wouldn’t want or trust a front-end guy to do, simply because security and scalability are hard problems. Would be nice if e.g. LinkedIn or a hosting company sponsor this by providing a number of open source scalable software in say containers/Kubernetes or whatever that will just work with Ember (SSR as an example, or deploying to only a subgroup - hand picked production users/early adopters, or deploy to one server/region to ensure nothing has broken before deploying out to everyone else, automatic rollbacks, etc.) and can easily be turned on and just works.
A start-up with a maxed-out credit card may not be thinking this far ahead, but if Ember offered this out of the box it may persuade new developers and/or start-ups to use Ember over something else if they can easily install a pre-configured secure production scalable solution (most just want HA but dream they’ll one day need scalable). I only mention LinkedIn because they have open sourced a number of software (assume ember compatible) and probably have the largest Ember team and are best placed to provide / sponsor and make available pre-integrated production Ember solutions/ecosystem that can be trusted to work.

Also, as someone who doesn’t live in the USA or a large country for that matter, mobile is the biggest consideration when choosing a language along with access to good developers, so React wins hands down here… you cannot even find an Ember or Vue dev here because of the demand for mobile which in turn drives people to learn React. I cannot stress enough the importance of a hybrid/native solution/option is needed ASAP! Great to see Chad do a PoC for NativeScript etc but seems to have gone quiet. Would also nice to see first class support for CSS Blocks, as I fair that may die off which would be a shame, as it seems quite quiet there and when people are even volunteering to fix performance/fundamental design problem (Parallelization #184), I don’t see anyone telling them to go for it...

Lastly, perhaps Ember 2020, after sorting out mobile native, could target other devices/platforms like Tv Browsers and apps (thinking Panasonic here have a lot of apps), Xbox, VR devices etc. Lots of potential users and potential paying customers are on these other platforms. A point of difference Ember could offer.

You would have quite a compelling story quite quickly for start-ups in my view.
I think the above can essentially tie into the developer focus of the RFC so hopefully it may at least start a conversation for considering other perspectives like StartUps and what could bring them onboard which in turn can drive more developer adoption of Ember.

Loading

@pzuraq
Copy link
Contributor

@pzuraq pzuraq commented Aug 4, 2019

I cannot stress enough the importance of a hybrid/native solution/option is needed ASAP! Great to see Chad do a PoC for NativeScript etc but seems to have gone quiet.

While it's not officially supported by the Ember core team, a community solution has been being worked for this actually! I've been helping out @bakerac4 when possible with Glimmer Native, and am excited to see where it goes too 😄

Loading

@unibum
Copy link

@unibum unibum commented Aug 4, 2019

While it's not officially supported by the Ember core team, a community solution has been being worked for this actually! I've been helping out @bakerac4 when possible with Glimmer Native, and am excited to see where it goes too 😄

I hope that Ember can pick up and officially support as anything that is done by a single person and not supported in core kind of scares me. I hope others get behind what @bakerac4 (and CSS Blocks) is doing.

Loading

@rajasegar
Copy link

@rajasegar rajasegar commented Aug 5, 2019

I am just trying to mind map the roadmap for my understanding.
ember-2019-2020-roadmap

Loading

@hjdivad
Copy link
Member

@hjdivad hjdivad commented Aug 12, 2019

@shankarsridhar @rajasegar thanks for pointing this out. The link in the description is now updated.

Loading

@jenweber
Copy link
Contributor

@jenweber jenweber commented Aug 13, 2019

@joukevandermaas RFCs usually have those sections. For long-term planning RFCs like this one or last year's roadmap, the "how we teach this" and "alternative designs" are not included. Instead, those sections will be covered in smaller, more feature-specific RFCs. For example, one goal last year was to use Native JavaScript classes, but the "how we teach this" goes in the RFC that is about that feature specifically.

Loading

@joukevandermaas
Copy link

@joukevandermaas joukevandermaas commented Aug 13, 2019

@jenweber thanks for the reply.

I'm confused because I think it is still a challenge to teach the community about the roadmap itself. I know from experience many Ember devs are not aware of long term goals of the project.

For alternative designs I was just curious what else was considered but dropped, and why.

Anyway thanks for explaining why these sections are omitted in this case.

Loading

@jenweber
Copy link
Contributor

@jenweber jenweber commented Aug 13, 2019

@joukevandermaas it’s definitely a challenge to get the word out. Overall I think there were about 30 different possible areas of focus proposed for the roadmap - too many to describe one by one here. Although we can only choose a few priorities for the Roadmap, many people will continue working on these other areas, and are encouraged to do so!

You can read more about the Roadmap process here: call for posts. I also recommend sharing the Ember Times with anyone who feels out of the loop. It's a lot to keep up with, so hopefully this Roadmap RFC is a good place where people can quickly review the plans. Thanks for reading this RFC and participating!

Loading

@jenweber
Copy link
Contributor

@jenweber jenweber commented Aug 13, 2019

One more thing, I think after the RFC is merged, we do still have work to do to circulate it. If you have ideas of places to share besides the Times, Twitter, and Reddit, please get in touch on the Ember Discord Learning channel. I think I understand now why you were concerned that the "How we teach this" was missing.

Loading

- **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
Copy link

@villander villander Oct 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this section should add ember-engines as well. Ember Engines is about packaging as well allowing for distributed development, testing, and packaging of logically-grouped pieces of an application.

And new build system will make ember engines more easy and stable removing most of ember-asset-loader in favor of embroider. We should figure out how code-splitting/tree-shaking will work with engines and if this is planned to this roadmap.

we will remove lazy loading and custom build from engines with embroider and Engines will be very fit with this. But engines still will be very recommended for complex architectures that need of microfrontends/separation of concern and we need ensure that ember engines will have their ergonomics problems solved (difficult to understand, implement test API, and bring router service to engines, dependency conflicts, separated builds/deploys and etc).

Loading

- **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.
Copy link

@villander villander Oct 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would put Fastboot because we do not have rehydration yet, we do not have good documentation and it seems to be a forgotten project. And SSR is indispensable in the current state of web.

Loading

Copy link
Contributor

@snewcomer snewcomer Oct 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I second the FastBoot goal. I'd be interested in the number of teams that are using the library or have forked for their own needs. It works well mostly in its current form for very large projects. But it would be good to lay out where the community feels some good progress can be had. I (we) have some ideas as to how to improve the ergonomics of the fastboot-app-server, but it seems like there are also ideas/concerns about it's current feature set.

Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I think Embroider (which is a goal) will take over the route based code splitting that FastBoot currently provides.

Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Panman8201 Fastboot doesn’t provide code splitting

Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦‍♂ My mind was elsewhere (ember-engines).

Loading

Copy link

@villander villander Oct 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ember Engines never was about code splitting. This is a confusion because engines was the unique way to reach this. So Embroider don't will replace Ember Engines, this was never the purpose

But ember engines is about isolation/separation of concerns, an antidote to many problems by allowing for distributed development, testing, and packaging of logically-grouped pieces of an application.

The right purpose can be found here - https://guides.emberjs.com/release/applications/ember-engines/

Loading

@mixonic
Copy link
Member

@mixonic mixonic commented Mar 8, 2020

Hello roadmap contributors!

2019 was quite a year for the Ember project. At EmberConf we publicized an alpha version of Ember Octane, and in December's release of Ember 3.15 we landed the real deal. Having a plan around Octane really focused contributors to Ember, and it focused the attention of those in the community as well.

In fact it focused us so much that the Steering Committee set aside the 2019-2020 roadmap to focus on Octane. At the end of the day I'm personally happy about where the framework is heading and proud of what the community got done, but before EmberConf 2020 I'd like to settle the roadmap process.

Yehuda and Tom have talked about framework feature cohesion as a cycle between "coherence and alignment" and exploration. In many ways the roadmap was intended to represent that same cycle for project priorities on a yearly cadence. The roadmap gathers input in the form of community blog posts, then it distills that input in a document ratified by the core teams and community. It should mark the moment when we're all on the same page.

But the prior roadmap cycle had some timing issues. For one, there is already a moment of high-cohesion in the Ember project and that is at EmberConf. It feels awkward to walk away from EmberConf straight into a discussion of what the goals for the year would be. We kind of squander the excitement and alignment of literally physically being in the same place by then jumping into a wide ranging exploration.

Instead we may be better served by the roadmap and EmberConf keynote being two presentations of a similar set of ideas. This means moving the roadmap discussion process to around January or February, and then using those posts, feedback from the community survey, and feedback from the core teams to ratify a roadmap in the weeks before EmberConf. Our highest point of alignment as a community is then at EmberConf itself, with a roadmap in hand.

...and fortuitously that is basically the timeline we're already on this year.

As the roadmap was based largely on community input from May 2019, we would like to provide the community another chance to chime in where they think any priorities have shifted.

The Steering Committee and myself have already updated the draft to reflect some of the things we would like to see as a focus post-Octane. I'll leave this draft open for another week or so and we can treat this like a standard RFC, then close to EmberConf I'll submit this for Final Comment Period and we and ratify our 2020 roadmap.

Please feel free to leave your feedback as comments on this PR, or add comments with links to your blog/social media. Finally you can join us #dev-rfc on Discord to chat about the roadmap.

I'm looking forward to your contributions, and to getting our community pointing in the same direction for 2020.

Loading

@Gaurav0
Copy link
Contributor

@Gaurav0 Gaurav0 commented Mar 9, 2020

For developers who are new to Ember, the presence of classic non-Octane APIs can be disorienting. Without setting a timeline for the next breaking semver release of Ember, we want to begin phasing out those APIs through deprecations. Some of this is trivial, but deprecating major framework features like Ember Components will be a multi-phase effort which requires careful planning. We're eager to build consensus on these large API removal efforts and see them underway in 2020.

I was very sad to see this paragraph. It is way too soon to deprecate non Octane APIs! I know some people are eager, but some enterprises have thousands of Ember Components and will simply not be able to remove them all in the next year. We should instead look to see how many of these features should be able to be removed from builds in newer applications through tree shaking and optional features.

As far as deprecations go, we should be concentrating on removing 1.x cruft, not non Octane features like Ember Components. For example, non closure actions and controllers. (We just need an official replacement for the route-action helper and query parameters on the controller.)

I also think we should be setting a timeline for a semver breaking release. We need to stop supporting IE11 because it is holding the entire framework back. Nothing stops us from doing another major release when we are ready, and there is a ton of IE11 cruft in our codebase, especially polyfills and hacks just to keep IE11 working. All of the polyfills need to be deprecated before we can land it, so a timeline of at least 3 months is required, and I'd prefer at least six months so that people can communicate with their customers and clients.

Finally, I'm going to miss the call for blog posts. I enjoy reading those.

Loading

@mixonic
Copy link
Member

@mixonic mixonic commented Mar 9, 2020

For developers who are new to Ember, the presence of classic non-Octane APIs can be disorienting. Without setting a timeline for the next breaking semver release of Ember, we want to begin phasing out those APIs through deprecations. Some of this is trivial, but deprecating major framework features like Ember Components will be a multi-phase effort which requires careful planning. We're eager to build consensus on these large API removal efforts and see them underway in 2020.

I was very sad to see this paragraph. It is way too soon to deprecate non Octane APIs! I know some people are eager, but some enterprises have thousands of Ember Components and will simply not be able to remove them all in the next year. We should instead look to see how many of these features should be able to be removed from builds in newer applications through tree shaking and optional features.

@Gaurav0 To start I will at least try to re-word this. It seems I failed to actually communicate the proposal. Ember.Component will be here for years. Period.

In this year we hope to start the design process for removal of some classic APIs. This is sure to include a bunch of RFCs to deprecate more minor and uncontroversial APIs, and maybe even RFCs for features to fill functionality gaps. Individual contributors will want to work on what interests them, and I think the suggestion of deprecating classic actions, for example, is great.

For the big items, like controllers or components or the object model, we're clearly talking about a timeline of years for removal. For many we will first need minor deprecation RFCs for uncontroversial removals and RFCs to fill functionality gaps. Only then can we start a deprecation RFC for a big feature, say Ember.Component, where we come to consensus on a phased path to deprecation and eventual removal. Obviously our goal is to bring every app forward, and feedback from app maintainers will be critical as we come up with a specific, concrete solution for these cases.

So by EmberConf 2022 we may have a deprecation in place for Ember.Component. At the least, I think we should have consensus on the path to removal.

This roadmap absolutely does not suggest that developers will need to port all their Ember.Component files to Glimmer components by EmberConf 2022 or risk falling behind on releases. In fact I was hoping it expressed a very reasonable, walking-pace process.

I also think we should be setting a timeline for a semver breaking release. We need to stop supporting IE11 because it is holding the entire framework back. Nothing stops us from doing another major release when we are ready, and there is a ton of IE11 cruft in our codebase, especially polyfills and hacks just to keep IE11 working. All of the polyfills need to be deprecated before we can land it, so a timeline of at least 3 months is required, and I'd prefer at least six months so that people can communicate with their customers and clients.

That is reasonable feedback. I'm personally eager to drop IE11. IMO we would need to do it at the 4.0 release where we could adopt a new platform support position. It seems like we're not pushing for a 4.0 though.

Finally, I'm going to miss the call for blog posts. I enjoy reading those.

The roadmap process absolutely should have a call for blog posts. This specific roadmap is odd because it was based on blog posts from May 2019. We could have declared bankruptcy and started a whole new draft, but as steering would like to change the timing of future roadmaps anyway we chose to base it on the prior posts.

So we should expect a call for blog posts for the 2022 roadmap around January of 2022, in the adjusted timing.

Loading

@Gaurav0
Copy link
Contributor

@Gaurav0 Gaurav0 commented Mar 9, 2020

Thanks for your followup explanations. I think we are then mostly in agreement.

That is reasonable feedback. I'm personally eager to drop IE11. IMO we would need to do it at the 4.0 release where we could adopt a new platform support position. It seems like we're not pushing for a 4.0 though.

I don't see why we should not be pushing for a 4.0 in order to stop supporting IE11. I opened an issue and it has received mostly positive feedback, albeit most of the core team has been silent. See #582

Loading

@chriskrycho
Copy link
Contributor

@chriskrycho chriskrycho commented Mar 31, 2020

I have two closely-related suggestion at a process level for this and following roadmaps (including but not limited to those which have Edition impact):

  1. Explicitly define "design periods" and "implementation periods" in the cycle. I'm borrowing a page here from Rust, where the idea of an "impl period" was tried to mixed success a few years ago—and because of that mixed outcome, I don't think we should do that in the sense that Rust did, where a short timespan was allocated for implementation, which led to a rush/churn/fatigue sense. Rather, I mean that as core teams identify that they've got enough work to do, intentionally and explicitly pause on further design work, and work to implement.

  2. Communicate more about the cycle of work. This picks up the "explicit" part of the previous bit. It's perfectly reasonable for there to be periods where core teams don't have bandwidth for reviewing RFCs—late in Octane implementation, for example, it just didn't make sense for anyone to be digging through more design work when we really, really (per our roadmap!) just needed to be finishing the work. It will help the community focus its efforts to explicitly communicate those kinds of things. A blog post that says "Hey, we're pausing on evaluating new RFCs until we finish implementing these RFCs, and in the meantime we're working hard on implementation. Here are the quest issues; we're happy to help you help us with them" would set expectations for everyone appropriately, and make it easier for the community to track where each Core team is at.

That second one, I recognize, involves more work for Core teams, and writing is not easy work! However, "more communication" has also been a consistent theme of the calls for blog posts results over the past two cycles, and I think just announcing "We're back to reviewing RFCs, and will aim to cover all open RFCs in the next <insert time period>" goes a long way—as would "Hey, quick update: we've been delayed on reviewing RFCs because <urgent thing> came up."

I think in general, everyone in the Ember community assumes the best of leadership's motives and direction, and vice versa; but more explicit communication in general helps keep those lines clear, and particularly consciously identifying and communicating the lifecycle of the project at any given time.

I look forward to seeing how 2020 goes (and hearing an update on this roadmap!).

Loading

@mixonic
Copy link
Member

@mixonic mixonic commented Apr 17, 2020

I folded in an update which strips the explicit example of Ember.Component from the roadmap, and which also makes clear that the goal is for non-Octane APIs to continue being available when needed while also making them cheaper (in payload, performance, and mental model) for new adopters.

Steering was discussing this roadmap regularly before EmberConf. Although we (I) didn't get it landed before the conference, and there have been a few distractions lately, we're ready to nominate this roadmap for FCP.

I'll share a little wordsmithing from @wycats:

In our meeting today, the steering committee agreed to (finally!) move this RFC into FCP (final comment period). Despite taking a little bit longer than we expected due to unforeseen circumstances (ahem, global pandemic), this has been a great year of blog posts and discussion around the roadmap. The big picture of the roadmap is continuing to build on Octane, wrapping up our work on our next generation build system, Embroider, and continuing our work on accessibility. Once the FCP is complete, we hope to publish the roadmap to mobilize this amazing community around this shared set of goals.

One last thing: remember that the work of the community and core team is broad and can't be fully captured in a high-level document like this. We are grateful for the heart and soul that our community pours into Ember. Let's continue to support each other!

Loading

@mixonic mixonic changed the title Ember 2019-2020 Roadmap RFC Ember 2020 Roadmap RFC Apr 17, 2020
@jrjohnson
Copy link

@jrjohnson jrjohnson commented Apr 17, 2020

In our upgrade to Octane we've been fighting the edition when dealing with async data and form validation and I'd like to see something about these added to the Invest in Octane section.

Landing @use should be a priority. I have trouble really understanding an API until I can work with it so that alone may solve many of our issues around Octane and:

  1. What to return from an ED model which depends on many layers of async attributes
  2. How to re-fetch (and re-render) a component when async attributes on a passed value change
  3. Best way to memoize an expensive async getter
  4. Lots of other one offs that come out in the day to day work of building a data driven ember app.

If @use doesn't turn out to solve these problems then there is some work to do in creating a happy path for async data.

Form validation in Octane is territory I think we're all exploring together. My team has been using class-validator decorators for the time being because I think decorators are probably the long term right validation choice, but everything we build there is guaranteed technical debt when/if new decorators land in ES20??. I think part of investing in Octane is going to be lobbying for a final decorator spec and I'd be interested in knowing what we, as a community, can do to help that along. Once decorators are official then it should be possible to build on the work of ember-cp-validations and create a consensus approach for form validation.

Loading

@knownasilya
Copy link
Contributor

@knownasilya knownasilya commented Apr 18, 2020

@jrjohnson regarding trying out use, a few months back @ef4 did a talk where he built out that decorator, see the code here https://github.com/ef4/jan2020-meetup-example/blob/master/app/components/use-decorator-station.js

Loading

@jrjohnson
Copy link

@jrjohnson jrjohnson commented Apr 23, 2020

@knownasilya that's a great talk and thanks for sharing it, but it's only getting at the simplest possible example for fetching async data. There is discussion at the end about a future where a task can be created as a resource and that may be the right path, but I don't see how to get there from the example. Async data fetching is one of those things where the easy example and the median use are so far apart as to be un-recognizable in the same solution.

A great part about that talk is that @ef4 explicitly calls using {{did-update}} a hack in January despite it being the recommended solution when we started our Octane migration in November. Patterns will change, but right now I don't think there is consensus even on the Core Team about how async data loading should work in components. When that recommendation exists I'd love to update ember-codemods/ember-native-class-codemod#219 to include it and update the guides to talk about it.

That lack of clarity is the main reason I felt compelled to bring it up in the context of this RFC.

Loading

@mixonic
Copy link
Member

@mixonic mixonic commented Apr 24, 2020

@jrjohnson Thanks for the comments!

I agree that the Octane APIs into reactivity need work. There are many intersecting issues and solutions. @use is one part, the recently merged destroyables RFC is another, and IMO the tracked map/set/array APIs are part of it. I expect a low-level references API will ship and some of those problems may be solved in core-adjacent projects. Component-level data-loading is a good example of a specific motivation for those designs.

The roadmap doesn't call out many explicit features in this area. I'm not sure it needs to at that level, as we don't want to confuse people that we've picked solutions outside the RFC process. @use for example is not in FCP, implying that there is still significant discussion happening.

I'm comfortable saying that form validation is not something we want to solve in the core framework. However, I agree that we should work as a community on a consensus solution! It is a challenging problem that would benefit from lots of 👀.

Loading

@mixonic
Copy link
Member

@mixonic mixonic commented May 1, 2020

Today at the steering meeting we reconfirmed consensus on merging this roadmap 🎉

My next step with this is to open a similar PR as a blog post for emberjs.com

I'm looking forward to a productive 2020 in the Ember project!

Loading

@mixonic mixonic merged commit c98bd19 into master May 1, 2020
2 checks passed
Loading
@delete-merged-branch delete-merged-branch bot deleted the 2018-2019-roadmap branch May 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment