Readers' Questions: "Why does Ember still use RSVP?"


nice to have utility functions to make that shorter and clearer

In general, I agree, but (tiny bit of devil’s advocate here) I do wonder if that lends credence to the idea that Ember has a “lot to learn”. Cause even utility functions that make things nicer have to be learned before being used. I’ve used the above Promise.all pattern in a number of different frameworks, so it didn’t even occur to me to look for the hash functionality until I saw people discussing it in conversation.


should we RFC to recommend not using RSVP, aside from utility functions like .hash?

Like, only warn about using promises without RSVP if the build target doesn’t natively have promises?


I’m not suggesting it should be built into Ember, I’m suggesting that a tiny, plain-Javascript library can and should do the job. Any people would only add it if they want it.


So it sounds like this is in the (near) future. Is there an RFC, a quest issue, and/or a pull request we can subscribe to to track this? Or is it already in canary/beta/stable? My biggest confusion around all of this is when the autorun will be embraced and how we can track when it happens.


It’s already in 3.4 stable.


The info in this thread is very interesting, thank you!

I am also interesting on it.

Then, it looks that from Ember 3.4; RSVP.Promise is not needed anymore, and we can start using native Promise instead (except for the RSVP non-spec API like hash, hashSettled...), is this correct or I misunderstood something?


Yes, you should be able to use native Promise. If you find any problems with that please report them.


@ef4 - please check out these 2 issues where I’ve given a few examples and reproductions of stuff that is broken:



I replied on the first issue, but for folks watching this thread, the summary is: the native promise works fine, but you need to write tests that actually await all the asynchrony you care about. await render() just waits for render to happen. It doesn’t wait for to fire. But you can wait for that with await settled(), or you can use the waitFor or waitUntil functions from @ember/test-helpers to observe the results of your asynchrony.

RSVP.Promise sometimes lets you accidentally write sloppy tests that don’t say what they’re really waiting for. Conceptually, this is a leftover from the old-style tests that would “magically” do promise threading. The new-style test helpers are designed to let you explicitly wait for things instead.

Another way to state the problem is: getting “magic” waiting in tests is a non-standard feature of RSVP.Promise. But we don’t need to use that magic waiting anymore if we use the new-style test helpers.


I have open an issue suggesting to remove RSVP from the latest docs.


@ef4 using native promise I still don’t have to worry about the loop running on tests, right?