Ember 2020 Roadmap RFC #519
Conversation
text/000-2018-2019-roadmap.md
Outdated
|
|
||
| Candidates for deprecation or extraction include: | ||
|
|
||
| - **Object utilities** such as `isBlank`, `compare`, `trySet`, etc. |
There was a problem hiding this comment.
Linking to @elwayman02's thoughts here: #516
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Linking as well to @snewcomer's older, similar proposal: #334
|
To point out the elephant in the room, 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. |
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. |
|
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. |
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. |
|
Before I mention what I think is missing, there's a lot that's great:
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:
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. |
|
That sounds great. Optimize for growth sounds a key here, specially to get more contributors. @barelyknown you have a good point
The 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. |
|
@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.
|
|
@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? 🤔 |
|
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. |
|
@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!) |
|
@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. |
|
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! |
@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.
I am 100% in agreement with this, so so much. |
text/000-2018-2019-roadmap.md
Outdated
| - **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. |
There was a problem hiding this comment.
Wondering if dynamic query params is something that could be explored as part of these changes!
There was a problem hiding this comment.
Dynamic route segments also! e.g. handling both foo.com/posts/:seo/:id and foo.com/posts/:id with the same route handler.
|
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 growthI want to mention three things concerning the "Accelerating ecosystem growth" goal: 🧳Ember-DataWe 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 I know this is a roadmap RFC for Ember.js but since Ember-Data comes as default with 👩🏼🔬 InnovationsWith 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 TypeScriptFor 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 thoughtsSince 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. |
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 😄
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. |
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. |
|
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 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 |
text/000-2018-2019-roadmap.md
Outdated
| @@ -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) | |||
There was a problem hiding this comment.
Reminder to add the link here! 🙏
text/000-2018-2019-roadmap.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
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!
text/000-2018-2019-roadmap.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
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.
|
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. 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. |
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. |
|
I am just trying to mind map the roadmap for my understanding. |
|
@shankarsridhar @rajasegar thanks for pointing this out. The link in the description is now updated. |
|
@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. |
|
@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. |
|
@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! |
|
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. |
ghost
mentioned this pull request
text/0519-2019-2020-roadmap.md
Outdated
| - **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 |
There was a problem hiding this comment.
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).
text/0519-2019-2020-roadmap.md
Outdated
| - **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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
FWIW, I think Embroider (which is a goal) will take over the route based code splitting that FastBoot currently provides.
There was a problem hiding this comment.
@Panman8201 Fastboot doesn’t provide code splitting
There was a problem hiding this comment.
🤦♂ My mind was elsewhere (ember-engines).
There was a problem hiding this comment.
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/
|
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. |
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. |
@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.
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.
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. |
|
Thanks for your followup explanations. I think we are then mostly in agreement.
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 |
|
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):
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!). |
|
I folded in an update which strips the explicit example of 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 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:
If 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. |
|
@jrjohnson regarding trying out |
|
@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 That lack of clarity is the main reason I felt compelled to bring it up in the context of this RFC. |
|
@jrjohnson Thanks for the comments! I agree that the Octane APIs into reactivity need work. There are many intersecting issues and solutions. 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. 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 👀. |
|
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! |
Original description
RFC sets the Ember 2019-2020 Roadmap. This year, our two priorities are:This RFC sets the Ember 2020 Roadmap.