The first one creates a new RSVP promise. RSVP promises are ES6/A+ compliant, so it's essentially a polyfill (with some extra features). Nothing wrong with doing this method.
The second case depends on the scope where the code is called. If you have a var Promise = RSVP.Promise; somewhere, they mean the same thing. However, if you haven't declared Promise yourself, this will likely fall back to the browser implementation (if one exists). Because RSVP is ES6/A+ compliant, you likely wouldn't notice if the browser implementation is used (unless you're using custom RSVP methods).
Short answer long: they might mean the same thing, but they might not.
Personally, I like the second method better because when RSVP is removed and the browser implementation is used, no code will have to change. I just do window.Promise = window.Promise || Ember.RSVP.Promise at the start of my script as a polyfill. But if you do that, be sure to only use the methods listed on this page, not any extra RSVP methods.
The first one creates a new RSVP promise. RSVP promises are ES6/A+ compliant, so it's essentially a polyfill (with some extra features). Nothing wrong with doing this method.
The second case depends on the scope where the code is called. If you have a
var Promise = RSVP.Promise;
somewhere, they mean the same thing. However, if you haven't declaredPromise
yourself, this will likely fall back to the browser implementation (if one exists). Because RSVP is ES6/A+ compliant, you likely wouldn't notice if the browser implementation is used (unless you're using custom RSVP methods).Short answer long: they might mean the same thing, but they might not.
Personally, I like the second method better because when RSVP is removed and the browser implementation is used, no code will have to change. I just do
window.Promise = window.Promise || Ember.RSVP.Promise
at the start of my script as a polyfill. But if you do that, be sure to only use the methods listed on this page, not any extra RSVP methods.