I agree with Paul-Sebastian Manole here. Also let's not forget how the JavaScript work behind the scenes. Promises are sent to the event loop to be processed once the stack is clear. There is a reason async functions are different from synchronous code that we write.
Hi Manik, thanks for the comment. You're right, JS is single threaded, but Promises technically use a separate "micro-queue" which recieved precendence over the event loop.
In either case, I mentioned "similar to multi-threading concepts" because of that fact of queues vs. threads. So you're correct, they are not the same!
But, if for a moment we set aside starvation (which is a real concern), and also web workers/etc -- then we really can conceptualize Promises as threads! And it's a very powerful way to think about them.
I've written up an Advanced JavaScript Promise slide deck; if you're interested I'll post the link.
That's why it's called JavaScript++, it's not backwards compatible and requires a new mental model 😉.
You could be right Eric Kwoka, I'm not familiar with the implementation details. That sounds like an efficiency optimization, though. But conceptually, to cover all the cases in a uniform way, the auto-boxing strategy could work.
(Promises are so cool. Just try Promise.resolve(Promise.resolve(5)) if you don't believe me, lol.)
But actually, I introduced it more as a (valid) concept to bridge us over to the async-by-default model.
Manik
Dedicated to @Cloudaffle
I agree with Paul-Sebastian Manole here. Also let's not forget how the JavaScript work behind the scenes. Promises are sent to the event loop to be processed once the stack is clear. There is a reason async functions are different from synchronous code that we write.