Hello there,
I’ll appreciate any opinions on my solution for this topic.
Thanks
Well done @texas-triumph!
For the first version you could also use nested .then()s instead of setTimeout()s. But I think we both agree that either of these are a mess. 
From the other two versions which one do you prefer?
Hello Michael!
My apologies for the pause with the answer and many thanks for your opinion. I appreciate it.
I was thinking about your remark concerning ‘nested then()s’ which once again dropped me down to the realization that this ‘asynchronous stuff’ drives me crazy. The subject of promises in particular looks like a slick fish tail – one moment I think I got it, and a second later I totally get lost with my logic. I was trying to compose the ‘nested then()s’ variation and included the relevant portion of code (https://github.com/BrendanWorley/testfield). Then I studied it and found a huge resemblance with the ‘promise’ variation in my code. I continue reading whatever I find on promises, resolve() and then() methods and I get a feeling that I need more practice in order to get a better understanding. The subject is really tough. So I’m very keen on what you may say on this portion of code I included here.
As for the other question, sure thing the ‘async await’ is way neater solution. In this regard, from the height of you experience, could you describe what is the most common practice in the community? What programmers are prone to use in the code when it comes to asynchronous stuff? Thank you.
Agreed 
That’s true. The only difference is that “Promise hell” nests the calls and “Promise chain” puts them in sequence.
I had a look at your version and you can make it simpler. The finished property itself returns a Promise that’s get resolved when the animation has finished. So we don’t need Promise.resolve(). (It just returns the Promise inside.) Promise.resolve() is useful if something expects a Promise, but we only have a “normal” value.
This is a simpler version of the “Promise hell”:
alice1.animate(aliceTumbling, aliceTiming).finished
.then(() => {
const alice2Animation = alice2.animate(aliceTumbling, aliceTiming).finished;
alice2Animation.then(() => {
alice3.animate(aliceTumbling, aliceTiming);
});
});
History time
Promises as native JS objects where introduced in 2015, but there where libraries like Q that implemented them years earlier in JS. (The first version tag of “Q” on GitHub is from 2010). The concept of Promises itself is even older and was used in other language before.
One year later async/await were introduced to JS to make working with Promises easier and to make it look more like synchronous code. So your observation that its a neater solution was exactly the goal.
I would guess most developers nowadays use async/await for this reason. At least that’s the case for me.
I hope this gave you a better understanding. Asynchronous code is a hard topic to wrap one’s head around; don’t get discouraged.
See you,
Michael
Hi Michael,
Many thanks for elaborations on .then()s. Wondering why I couldn’t guess myself, all the more I saw that remark on that that the ‘.finished’ was in fact a promise upon which resolution we could launch another .then(). …. fish tail indeed ))) in my case too much of the theory demanding a decent amount of practice. got to work on it more.
Particular thanks for the excursion into Q/promise/async history. Seems like something always precedes something… surprisingly, I’ve never met the “Q” mentioned when read about async stuff.
1 Like
indeed much simpler…
alice1.animate(aliceTumbling, aliceTiming).finished.then(() => {
alice2.animate(aliceTumbling, aliceTiming).finished.then(() => {
return alice3.animate(aliceTumbling, aliceTiming);
});
});
1 Like