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

RFC: Ember 2018 Roadmap #364

Merged
merged 4 commits into from Nov 1, 2018

Conversation

Projects
None yet
@tomdale
Copy link
Member

tomdale commented Aug 24, 2018

This RFC sets the Ember 2018 Roadmap. This year’s goals are to:

  • Improve communication and streamline decision-making, and empower new leaders.
  • Finish the major initiatives that we’ve already started.
  • Ship a new edition, Ember Octane, focused on performance and productivity.

A sincere thank you to everyone who tweeted, posted in the forum, and wrote responses to the #EmberJS2018 call for blog posts. We were blown away by the outpouring of thoughtful, insightful feedback.

One note about the time period. We intend for this 2018 roadmap to cover the time period from now until around March 2019, to coincide with EmberConf. Our goal is to continue this process on an annual basis.

Rendered

@rtablada

This comment has been minimized.

Copy link

rtablada commented Aug 24, 2018

One thing that I worry about is the discussion and communication of "Glimmer.js", "Ember", and "Glimmer VM". Now with the "Ember Editions" I think this is muddied even a bit more.

I think clarifying what Ember Octane is missing vs Glimmer.js (or the old promise of Glimmer.js) would really help clarify this discussion.

In the RFC you mention

Significant work on Glimmer.js. We will instead focus on our efforts on incorporating the lessons of Glimmer.js into work that enables a smaller core in Ember.

This is a bit confusing whether this means that Glimmer.js becomes Octane or if they remain separate? Even if Octane isn't the Release edition that is "Just components" or progressive Ember, I think a solid clarification in direction of what the progressive story is (or if that is out of scope).

@chriskrycho

This comment has been minimized.

Copy link

chriskrycho commented Aug 24, 2018

  1. 🔥 this is excellent.
  2. Following up on @rtablada's comment, similar elaboration/clarification on the "npm-install-your-way-to-Ember" goal that has been floated off and on for the past few years could make this even clearer. If I'm reading it right, implementing the RFC will actually accomplish that—but it's not clear.
@cafreeman

This comment has been minimized.

Copy link

cafreeman commented Aug 24, 2018

I know it might just be too early to say, but I think the section on communication and stream-lining communication could be fleshed out a bit more with some details on what the implementation of some of those bullet points would (or could) look like. For example, the "invest in mentoring" bullet point sounds like it's chock full of potential for bringing a lot more effort to bear on growing and supporting Ember itself, but I'm immediately curious about how we could facilitate "direct mentorship relationships".

On the one hand, I understand that this isn't necessarily supposed to be a commitment to an exact plan, but I also think it'd help open up the discussion if there were some indication on what the core team is considering for that stuff.

Edit: I was remiss not to mention that I think this great and I am utterly thrilled to see the Ember2018 push starting to bear fruit.

@apellerano-pw

This comment has been minimized.

Copy link

apellerano-pw commented Aug 24, 2018

Ember Octane is marketed toward new Ember apps but I think it should also explicitly state its relationship with existing Ember apps. Is Ember Octane a party we should all show up at? Will we have help getting there? That seems like it would benefit the community the most.

I maintain a 4 year old Ember app that started on Ember 1.0 and we have gone through so many upgrades (ember-cli, pods, 2.0, glimmer 2) that we're a 2.18 app, but a well-worn and bloodied 2.18 app.

We know the long-term developer benefits of staying within radius of the Ember community but it can still be difficult to justify our upgrade efforts to those thinking more directly about customer benefit. What helps to get them on board is to offer them a picture of how these upgrades don't just benefit our development team, but also benefit our customers.

My guess is showing these sorts of things would also aide you in pitching Ember Octane to new users, so I don't think I'm asking for more work; just for two perspectives to be considered on the existing work. Saying "native js classes perform better" and accompanying it with a graph showing the performance improvement would be absolutely priceless when we go to bat for the next round of upgrades.

@mike-north mike-north referenced this pull request Aug 25, 2018

Closed

[RFC / Quest] Decomposing types into @ember modules #250

13 of 13 tasks complete
@ahawkins

This comment has been minimized.

Copy link

ahawkins commented Aug 26, 2018

I'm happy that this process exists. I respect the Ember community and the core team for driving consistent improvement over years. I mean it when I say years. Ember was rough years ago. I don't think that's the case today. The documentation and guides are great. Technically things work to the point where I don't assume everything is broken. Ember CLI makes it easy to build, develop, and deploy ember applications. I haven't had my finger on Ember's pulse for a while now so just a few things stood out to me:

  • An updated homepage. I agree. The aesthetic feels data and can pitch Ember more in relation to other options
  • ES6 classes and modules. I look forward to using modern JS concepts to write Ember applications. Especially async and `await.

Anyways, I'm confidence the Ember team and community and produce a strong octane release. Best of luck to everyone involved. I'm happy we have a stable project in this space and the RFC process keeps it that way.

@jgwhite

This comment has been minimized.

Copy link

jgwhite commented Aug 26, 2018

This is very exciting and a great crystallisation of everything the community expressed in the blog post series.

I’m also a little confused about what exactly Ember Octane will be. Will it be a different package to mainline Ember? Or a marketing name for whichever regular train release happens to contain all the Octane features?

@mfeckie

This comment has been minimized.

Copy link

mfeckie commented Aug 27, 2018

This is a really great, positive document that addresses many of the concerns I recently shared in the Ember forum.

I'd really like to see geographic diversity addressed in the mentoring / communication focus.

I'm also particularly interested in the 'discoverable communication'. I think having a better / clearer source of truth for the core team plans would be great. I know that some things already exist, but I feel like you have to be 'in the know' to access / find them. Would be nice to see this change to a 'push' process vs the current 'pull' style.

@mikkopaderes

This comment has been minimized.

Copy link

mikkopaderes commented Aug 27, 2018

I'd like to suggest that we align our status board to what's in plan for the yearly marketing release. Currently, some of the changes outlined in the RFC aren't there. This would give us a quick sense on what's the status on the major changes promised to the community.

In addition to that, I'd personally like to see the status board be part of the homepage. Not hidden under some navigations. This would give old and newcomers a quick insight on what's happening in Ember.

Ember releases a new, stable version every six weeks. For existing users, this drumbeat of incremental improvement is easier to keep up with than splashy, big-bang releases.

However, for people not following Ember closely, it’s easy to miss the significant improvements that happen over time. As detailed in the forthcoming Ember Editions RFC (being worked on by [Dave Wasmer](https://twitter.com/davewasmer)), every year or so **we will release a new edition of the Ember**, focused on a particular theme. The set of improvements related to that theme, taken together, mark a meaningful change to how people should think about Ember.

This comment has been minimized.

@TRMW

TRMW Aug 27, 2018

Edit:

we will release a new edition of the Ember

@jessica-jordan jessica-jordan referenced this pull request Aug 28, 2018

Merged

The Ember Times - Issue No. 62 #3533

5 of 5 tasks complete
@elwayman02

This comment has been minimized.

Copy link

elwayman02 commented Aug 29, 2018

Nothing for module/bundle splitting? Is that so far off or so dependent on Module Unification that it doesn't warrant mentioning in this RFC in its own right?

@tomdale

This comment has been minimized.

Copy link
Member

tomdale commented Aug 29, 2018

@rtablada I don't think we will have the full "npm install your way to Ember" story done in the Octane timeframe, although we will have made significant progress towards that goal.

I think of Ember Octane as being part of a 'tick-tock' cycle of experimentation. We did a ton of really great R&D work in Glimmer.js, but we need to make sure that work translates into a day-to-day improvement for Ember developers. Ember Octane is about making sure the work we did in Glimmer.js is available to Ember users in a backwards-compatible way.

Glimmer.js remains very low-level, and does not contain functionality that most people need, like routing, a data layer, etc. Even the addon story remains quite limited compared to Ember. That said, there will still be use cases where Glimmer.js would work but Ember Octane might not. For example, if you're targeting emerging markets with 2G data networks, even Octane's reduced size is likely not small enough.

In short, this roadmap does not talk about "npm install your way to Ember" because there is too much work and design left to do to feel confident about landing the full story in the Octane timeframe. That said, I think we'll be well positioned to do the final planning and UX design of "npm install your way to Ember" as one of our top priorities in the post-Octane 2019 roadmap. Over time, my expectation is that Glimmer.js and Ember.js organically "merge," and Glimmer.js is just an Ember app with the non-component packages removed.

@tomdale

This comment has been minimized.

Copy link
Member

tomdale commented Aug 29, 2018

@cafreeman

I know it might just be too early to say, but I think the section on communication and stream-lining communication could be fleshed out a bit more with some details on what the implementation of some of those bullet points would (or could) look like.

Totally agree. I have updated that section with a little bit more detail, but I would love to hear what suggestions you have for how we can improve mentoring systematically.

@tomdale

This comment has been minimized.

Copy link
Member

tomdale commented Aug 29, 2018

@apellerano-pw

Ember Octane is marketed toward new Ember apps but I think it should also explicitly state its relationship with existing Ember apps. Is Ember Octane a party we should all show up at? Will we have help getting there? That seems like it would benefit the community the most.

Fear not! Ember Octane, and editions generally speaking, are primarily a learning tool and a way to rally the community around changes to the programming model. Ember Octane is still Ember, and there are no changes to our stable/beta/canary/LTS release cycle. "Upgrading to Octane" will be no different than any other Ember upgrade.

@jgwhite

I’m also a little confused about what exactly Ember Octane will be. Will it be a different package to mainline Ember? Or a marketing name for whichever regular train release happens to contain all the Octane features?

See above. 😁

I apologize for the confusion around Ember Octane and releases. @davewasmer is working on a related Editions RFC that clarifies many of these details. I didn't want to delay getting the roadmap RFC out, but I also realize it's a bit unfair to have a big chunk of it predicated on another RFC you haven't even seen yet!

We will get that RFC up ASAP, and once people have had a chance to review, we can consider whether there's additional clarification/detail that would be appropriate to include in the roadmap RFC itself.

@tomdale

This comment has been minimized.

Copy link
Member

tomdale commented Aug 29, 2018

@mfeckie

I'd really like to see geographic diversity addressed in the mentoring / communication focus.

I updated the communication section a bit to touch on this concern explicitly. Are there specific things you think we can do to support global contributors?

(And thank you for your forum thread. It has been very helpful in understanding where we need to make changes, and I appreciate the time and courage it took to write it.)

@tomdale

This comment has been minimized.

Copy link
Member

tomdale commented Aug 29, 2018

@elwayman02

Nothing for module/bundle splitting? Is that so far off or so dependent on Module Unification that it doesn't warrant mentioning in this RFC in its own right?

I'm dying for this myself. Realistically, I give it maybe 50/50 odds whether we can ship this in the Octane timeframe. (And by "shipped" I mean stable, documented, on by default, well-supported by addons, etc.) I was trying to keep this roadmap towards the conservative side, but I would be happy if it landed soon enough to make it. I think it's next on the list post-Octane if it doesn't make the first cut.

@betocantu93

This comment has been minimized.

Copy link

betocantu93 commented Aug 30, 2018

A nice community effort would be to update some of the most used addons to stop using JQuery especially preparing for Ember Octane. Most of UI addons I've used assume jquery is there, which makes it hard to just strip it off from current apps (as much as we would like to), and will possibly force many Ember Octane new users to add JQuery back to use these addons. I can name two right now that would be great: ember-cli-swiper, ember-paper

I would gladly help and attempt some PRs

@acorncom

This comment has been minimized.

Copy link
Member

acorncom commented Aug 31, 2018

@betocantu93 we've been working on the framework side of helping jQuery become optional here (emberjs/ember.js#16058) and folks have been switching the addon blueprints to encourage. Would love to have your help though!

@blimmer

This comment has been minimized.

Copy link

blimmer commented Sep 2, 2018

Content apps, where pages are text-heavy and where the first load is critical. In performance-constrained environments, Ember’s strong conventions can help developers build faster apps by default.

My team has an Ember app we've upgraded from pre-ember-cli days that has a mix of "productivity" and "content" apps. I have been really tempted to use something like Gatsby.js to pre-render and get a fast time to first load with rehydration of JS features. If ember had a good story around this use-case, we'd gladly remain with Ember on the Content App side vs. using something new.

So, I'm very excited to see this on the list of use-cases being focused on this year. One thing that I think is a bit confusing is how these themes (performance and content apps) ties into the rest of the document. Is Ember Octane edition solving for the Content App use-case?

@webark

This comment has been minimized.

Copy link

webark commented Sep 2, 2018

@blimmer not to get sidetracked, but did fastboot with rehydration not fit your needs? https://github.com/ember-fastboot/ember-cli-fastboot/blob/master/README.md#rehydration

Is a more “friction free” fastboot story part of ember octane? it mentions “Incremental rendering and rehydration” in the list, but never called out fastboot directly.

@blimmer

This comment has been minimized.

Copy link

blimmer commented Sep 3, 2018

@webark the biggest reason I'm interested in Gatsby's story around this is that the content is 100% pre-rendered. Therefore, you don't have to run (fastboot) servers to get this behavior. You get really great scalability because everything's just static files behind a CDN.

With something like Fastboot or prember + fastboot, there's a bottleneck at the fastboot server layer.

@acorncom

This comment has been minimized.

Copy link
Member

acorncom commented Sep 4, 2018

@blimmer actually, with prember / fastboot the story is the same as Gatsby (100% pre-rendered content) with Fastboot only involved in helping produce the content on a CI server (or equivalent). It's what we're doing for the guides (and we're slowly switching other Ember sites over to that as well). To keep from cluttering up this RFC, let's continue this discussion elsewhere (you know where to find me 😉 ). If others are interested in talking about it further, do ping me on Discord

@runspired

This comment has been minimized.

Copy link
Contributor

runspired commented Sep 7, 2018

Non-goals

Major new Ember Data features. We will instead focus our efforts on stabilizing Ember Data and updating it to align better with Ember Octane idioms

We should re-word this to make it clear that in order to modernize, improve stability, and better prepare for a lighter, more nimble future we will be continuing to invest in improving the architecture of ember-data and that such improvements will likely include changes to the public API.

One such example that comes to mind is RecordData; however, there will be additional modernization and re-architecture efforts within the Octane time period.

@tomdale

This comment has been minimized.

Copy link
Member

tomdale commented Sep 11, 2018

I updated the RFC text slightly, both to add more detail to the communication section, as well as to move Ember Data from the "non-goals" section to the Ember Octane section (based on @runspired's comment above).

@locks locks referenced this pull request Sep 20, 2018

Open

Editions #371

@Gaurav0

This comment has been minimized.

Copy link
Contributor

Gaurav0 commented Sep 21, 2018

How are we going to make upgrading to Ember Octane "just another upgrade" if the blueprint for new applications is updated in ways that break compatibility (such as not including jQuery by default)? Currently we update our apps to the same blueprint as new apps via ember-cli-update.

@kategengler

This comment has been minimized.

Copy link
Member

kategengler commented Oct 4, 2018

This RFC was discussed during core meetings in September and we decided to move to Final Comment Period. Details of how editions will be managed will be worked out in the Editions RFC

@Gaurav0

This comment has been minimized.

Copy link
Contributor

Gaurav0 commented Oct 4, 2018

I'd like to renew my previous question about upgrading apps. If we turn off jQuery in the blueprint how will we not do this for apps upgrading via ember-cli-update?

@rwjblue

This comment has been minimized.

Copy link
Member

rwjblue commented Oct 4, 2018

@Gaurav0 - Great question, sorry I missed it. I think we need to discuss the concrete specifics over in the Editions RFC, but the rough shape of things is probably something like (from this conversation in discord):

  • have ember-cli infer the "new app blueprint" from the projects .ember-cli file. This would be used for ember-cli-update / ember init purposes
  • create the new octane blueprint, making it the default for new apps (when the edition is "shipped")
  • update ember-cli-update to check the projects .ember-cli file to know what "kind" of project it is, and update accordingly
  • create a command the "migrate" to the edition (e.g. to go from the current default blueprint to the new one), separate from "simply" upgrading

After this is done, all ember new foo will get the octane edition blueprint, existing users would get their current blueprint updates, users of existing apps can easily migrate to the edition and know that they have done it correctly.

I'll cross-post this in the editions RFC so we can chat about it over there...

@auvipy
Copy link

auvipy left a comment

sounds great overall!

> When you generate a project with `ember new`, you get a project that is almost “legacy” by standards of the wider JavaScript community.
> —[Gaurav Munjal](https://medium.com/@gauravmunjal_86037/stability-without-stagnation-in-2018-ce2d4f519991)
> Ember's custom object model isn't hard to learn, but it's a big reason people are turned off before learning why Ember is such a great choce. I'd like to see ES classes support finished and adopted in the Guides ASAP, followed by decorators.

This comment has been minimized.

@auvipy

This comment has been minimized.

@rtablada

rtablada Oct 23, 2018

I'd like to see ES classes support finished and adopted in the Guides ASAP, followed by decorators.

I think guides would need to wait on decorators to adopt ES classes because of common uses of service injection and actions.

@jbailey4
Copy link

jbailey4 left a comment

This is exciting! Everything I think Ember needs to help showcase its true potential, which sadly gets underestimated.

- **Glimmer Components** as the default component API.
- **Native JavaScript classes** as the default object model.
- **Native JavaScript modules,** including:
- **Exposing modules in the build pipeline** and allowing addons to integrate tools like Parcel, Rollup or Webpack.

This comment has been minimized.

@jbailey4

jbailey4 Oct 10, 2018

Allowing addons to integrate tools like Webpack for example, is this basically referring to the Packager api in ember-cli, ultimately enabling code-splitting?

@wycats

This comment has been minimized.

Copy link
Member

wycats commented Nov 1, 2018

This RFC was moved into Final Comment Period 29 (!) days ago without much further discussion. At this point, I think it's safe to say we've already been operating as if it were merged, so I'm going to go ahead and merge it.

@wycats wycats merged commit 0a1b097 into emberjs:master Nov 1, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Gaurav0

This comment has been minimized.

Copy link
Contributor

Gaurav0 commented Dec 6, 2018

@tomdale

  • Glimmer Components as the default component API.

refers to @glimmer/component or @glimmer/component/compat when generating a new component?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment