I was wondering why Ember uses RSVP promises instead of native ES6 promises. Some of the older posts mentioned the vices of jQuery deferred, but now that we have ES6 promises in almost every browser, is there a reason Ember hasn’t switched to using those instead of RSVP.promise?
One of the drawbacks of Ember for me is having to use ember syntax instead of vanilla js (i.e. this.get(‘foo’) instead of this.foo). It’d be awesome if promises weren’t a different syntax in ember as well.
My guess is that it’s because ES6 promises weren’t available back in the day so RSVP was added as the promise library of choice. I’d also assume that the core team intends to move away from RSVP promises in favor of ES6 promises (it seems they prefer to stick close to js core when possible as opposed to including extra stuff) however that can take time. There’s a lot of stuff to consider from a framework standpoint in terms of backwards compatibility, upgrade path, and of course all the work to actually implement the switchover.
So in summary: this is just a guess on my part but I’d assume that the intent is to migrate eventually, but that takes time. I didn’t look to see if any RFCs or projects were already underway, but that might be the case also.
I don’t think that’s necessarily the case in all tests. You can still reliability use ‘const done = assert.async()’ and call ‘done()’ in the then() or catch().
This ~RFC points to some of what RSVP does and what async/await would also need to do somehow to be usable in app code (without Ember.run() everywhere):
It will work fine… until you try to test it. Any calls to get or set outside of the ember run loop will throw an error. We’ve had a few very hard to debug issues where somewhere in the code we accidentally made a call to the native Promise instead of RSVP.Promise. Solved that by banning destructuring { Promise } = RSVP. Now we know at a glance if something is using RSVP.Promise or not.
