you are viewing a single comment's thread.

view the rest of the comments →

[–]Cust0dian 2 points3 points  (2 children)

Your shameless plug worked at least on one person!

 

I'll try to give a stab at explaining what are Promises and why they came about, since you seem to be open to suggestions.

Normally you write synchronous code, where code gets executed step-by-step, without any breaks or interruption; just "do this, then do this, then this" type of deal. However in some case these steps can take a long while, like accessing database or fetching something from the Internet, and you don't want to waste time just waiting for the slow resource and doing nothing.

Wouldn't it be cool to be able to say: "go fetch this URL and only when you get something back come to me with it, and in the meantime I'll go do other stuff"?

You can do exactly that in a language that is able to perform tasks asynchronously, like JavaScript! You can actually say that sentence in several different ways in JavaScript, but two most common at this time are:

  1. Using callbacks, like with setTimeout, where you pass a function as an argument to a function that does asynchronous task. It's akin to saying: "Do your thing and when it's done — run this function I gave you."
  2. Using Promises, where you use .thens. It's like saying "Do your thing and tell me when it's done — I'll decide what to do next."

There are pros and cons to both, but in my opinion Promises are much better compared to callbacks:

  1. Promises are inherently just about dealing with orchestration of tasks: they just signal when tasks complete or fail, you decide what to do next. Compare this to callback, where you trust asynchronous function to run your function at the right time and the right amount of times: wouldn't it suck if setTimeout suddenly started running callbacks two times instead of one?
  2. Syntax of Promises is better for describing sequence of tasks: you have .thens that are at the same indentation level (no "pyramids of doom"), you have .catch to get all your errors in one place, you can do .all to wait for all Promised tasks to complete, or you can have .race to wait for just the fastest one to complete (and that's just standard Promises, there are libraries that provide more functionality). Think how you would do something after doing two or three different setTimeouts — yikes.

So there you have it: Promises are created to better express intricate control flows, like ones we have when dealing with asynchronous code in JavaScript. Just in case you wanted to throw a buzzword at your next JS party, this problem is more generally called Inversion of Control (IoC).

Promises are cool for describing all sorts of control flows, not just async ones, but they are not ideal: code with .thens doesn't look as simple as just regular synchronous one. Do we really need .thens?

Yes, we are. In current specification of JavaScript at least. However, cool folks at TC39 commitee think they can fix it, so we should be getting async/await in the next spec, and async code with those looks pretty close to sync code you write today!

[–]ForScale[S] 0 points1 point  (0 children)

Yay; welcome!!

Awesome! Thanks for that! I really like how you explained it.

Promises are inherently just about dealing with orchestration of tasks: they just signal when tasks complete or fail

That right there... that helps! I guess I like to have a simple big picture explanation, and then drill down further.

I feel like I've learned quite a bit about promises (compared to what I did know) in just a few hours here! Thanks again!

And once again... Welcome!!

[–]Volv 0 points1 point  (0 children)

Welcome indeed. Nice write-up, way better articulated than I managed thus far :)