JavaScript Promises Crash Course

[@shams_shimul]

Here's my appreciation for both of you two: Thanks a lot for making this video. The lesson is nicely formatted starting with a basic Promise and slowly progressing to a more complex structure and finally into the async/await construct. This has been my go-to reference whenever I get stuck with Promise/async-await and it bails me out every time. Thank you so very much. Be blessed guys ❤

[@teugene]

I wish Chris has a KZbin channel with lessons like this. The way he explains JS is so easy to absorb and understand.

[@Killyspudful]

He does: www.youtube.com/@gomakethings

[@aditideshpande3799]

i think he has one already...go make things!

[@BienvenidoSantibanez]

the name of his youtube channel is "go make things"

[@markayyy99]

This was a great explanation and definitely furthered my understanding. Please make more JavaScript videos like this, they help so much. Many thanks!

[@Uncaught_in_promise]

Please please more JavaScript tutorials. This is good stuff always in demand.

[@philippkewgvfds2190]

bro i just watch this comment and while i do this i fart in my hand and then smell my hand xd the smell is like egg xd its so brutal smell and i still smell it when i writing this comment xd

[@LordValtrius]

One thing that was skirted around but not touched on is that a promise saved to a variable but isn't chained will cache it's value for future then's, making it perfect for caching since most caches only check if the value exists and sends another request, not if the value is being fetched. Eg: const question = Promise.resolve(42) question.then(answer => console.log(answer)) question.then(answer => console.log(answer)) You get 42 logged twice, but if you were to chain them instead, the second would log undefined since nothing is returned from the first. Great video too, keep it up.

[@asagiai4965]

Because everytime you chain a promise the previous chain returns the answer.

[@raystorer633]

Kevin, thanks for having Christopher on to explain Javascript promises. He did a great job!

[@4ssguard]

After all of struggling with asynchronous JS operations and barely knowing what is going on in those cases Chris finally break the wall of my misunderstanding! Big thank you sir for such a great explanation and thank Kevin as well for all of your work!

[@ittixen]

I love those. I was hoping he'd mention how promises returned from another promise kinda automagically get then()'ed, because it really tripped me up when I was first learning promises, and honestly I still to this day didn't manage to wrap my head around it.

[@bryanmyers9977]

I'm really loving these JavaScript videos. The timing is perfect for me because I'm refreshing my skills before going out for a job. Chris is one of the best teachers I've ever seen for this. Very organized and clearly communicated.

[@daveturnbull7221]

Saw the title of this and instantly started preparing my braincell to be blown away. This is a topic I've struggled with from the moment they were introduced.

[@flpflpflp]

Really good video, thank you both for taking the time to record it!

[@tazerah1993]

Chris is a great teacher, but I'd love to see you engage more in the topic when you have guests on! Maybe re-contextualize the subject in a way that was helpful for you, or ask questions that you think a beginner might ask. Love the videos, Kevin. Thanks!

[@Lonchanick]

I loved the explanation at the beginning!

[@jonux13]

Thanks kevin and Chris, finally understand promises and async await functions, greetings from Argentina!!

[@osamudiameh_sama]

I pumped my fist when I saw the notification,promises been giving me a tough time. Thanks for this kev

[@aditideshpande3799]

i genuinely admire you guys for all the knowledge you give us! thanks so much Kevin and Chris! 🎉

[@JohnSmith-op7ls]

Async, Await. It’s not the dark ages.

[@jfftck]

It depends on your needs, but generally use the async function before using then, as most developers find it easier to reason about.

[@JohnSmith-op7ls]

@@jfftck Maybe there’s some rare or contrived case where a promise is better but I’ve yet to see one and there’s a reason why other languages never went down that path and just implemented the async and await syntax. I have’t seen a case in those languages where you’d want or need a promise syntax. Promises do the same thing but are overly verbose and often lead to nesting issues which cause maintenance, debugging, and readability headaches.

[@rockatanescu]

@@JohnSmith-op7ls I think it's much better that they started with Promise and then moved to async/await. I am fairly certain that most people writing JS/TS code nowadays don't really understand what async/await do.

[@dealloc]

Async/await is not mutually exclusive with Promises. Async/await is just syntatic sugar for Promise control flow. There is no "promise syntax". Promise is the API, async/await + try/catch is the control flow to deal with promises. Other languages implements the same concept; have an API (i.e. "Futures" or "Task") and provide syntax to handle the control flow (async fn / do_thing().await, await doThing(), etc.). You're still dealing with those things under the hood-you don't get to choose.

[@JohnSmith-op7ls]

@@dealloc I mean, above bytecode, it’s all “syntactic sugar”. Semantics aside, the point is, why use a more verbose, more difficult to read and maintain way to accomplish async coding when you don’t have to. Where’s the benefit? Working directly with threads is a pain so you need a good reason to. JS doesn’t give you that option so you’ve got two ways of telling the JS engine to do async control flow, why not use the simpler one.

[@mathiascunault2972]

clear and precise with increasing complexitiy. More stuff like this ! 🙏

[@jfftck]

If you ever hear someone talking about a function’s color, it is just saying that asynchronous and synchronous functions are a different “color” and you can only use synchronous functions inside asynchronous ones, but not the other way around. It is just easier to remember that async doesn’t return a value directly, so to wait for it, but to be able to do anything else, you will also need to wait for the parent function as well, all the way until the top function is reached. This is one of the most common issues new developers encounter and have difficulty with understanding. This video didn’t explain how asynchronous functions work inside the JavaScript runtime, but the simple explanation is that there are three ways functions return a value: just calling a regular, callback for an event, or resolving a promise. So, there is a loop that checks stacks for code to run and it has to check three of them, the first stack is ran immediately, and the next two are added to the first when the condition has been met - like the event being triggered or the promise resolved/rejected. That is why you can’t call asynchronous functions inside synchronous ones, they don’t exist yet in the stack and will only exist after the next iteration of the loop.

[@maciejzettt]

You can call async functions inside synchronous ones but you have to register the callback in its scope by calling .then()

[@jfftck]

@@maciejzettt You pass a callback into the then, and it still is called after the function exists, try putting a message in an element on the page or out to the console inside the then and just before leaving the function, it will be the message you put in just before exiting the function that will be displayed first. You are no longer coloring the function, but it is still out of order execution, which is the only way to use the promise inside of a regular function.

[@maciejzettt]

I agree with you when it comes to the outcome and internals, but you technically call that async function, i.e., initiate its execution from within the sync one. It's just that the following code outside of the callback doesn't wait for the result. And it doesn't wait only if the resolution of the async function waits for results from outside of the JS engine, otherwise, as you said, the function runs until it returns and blocks the event loop. It's only a conceptual thing as there's no point in writing such heavy-working functions as asynchronous or even writing them in JS at all. I wanted to show that although completely wrong and nasty, you can imagine such async function which could be called and even completed in the lifetime of the outer synchronous function's scope.

[@bobmonsour]

Today I learned about "finally." Finally! Personally, I prefer the async/await approach as that is how I first began to understand Promises.

[@pchinnakasaiah8492]

great clarity i finally understood promises thank you sir

[@modi_hemnt77]

Loved this tutorial!! Please more of this.

[@whatisthis__95]

I don't know why people keep saying in tutorials that applying the .json() method to a response (for example) gives you a JSON object, when actually it returns a JS object (plain old regular object). That must confuse a lot of people

[@hoshi411]

I love that you are doing these javascript dives but if I wanted a dictionary definition of these things , I can just read a dictionary. This didn't answer the questions that I needed answered for me to actually understand promises. I needed him to explain what people did before promises existed. How did they get stuff done without a promise style function and how did promises then improve their life using examples. I also needed to get more real world situations where a developer comes across an issue and thinks, "this is exactly where I should use a promise." I write javascript web apps myself and I have never used a promise. Should I be using them? Why , if I am already living life without them? How can they help me. He needed to show code solutions without promises and then show the problematic nature of that and then bring along the hero "dun dda da dan !!! The Promise!" and show how that brings light to the problem. All he does in these videos is read from a dictionary of what a promise is. that is not helpful. Please make the video again but do it in the format that I have suggested here.

[@dealloc]

What we did (and still do) was using events and callbacks. In other cases it would be blocking, like XMLHttpRequest before `fetch` API.

[@DanielGrima90]

@hoshi411 I would suggest reading a bit about JavaScript "Callback Hell" which sometimes is also called the "Pyramid of Doom". This should give you a very good idea why Promises were created and why they are used. Most times the fetch API is used to showcase Promises and API calls. However in the JavaScript world nowadays where before we used callback functions we now have Promises. This is not to say that callbacks aren't used, they still are, but if your code is asynchronous Promises are recommended. They are easier to read, maintain and handle errors better :)

[@stephaniepeters2590]

How are you handling API requests then? Are you still using XMLHTTPRequest? Or a library such as axios (in which case I guess you would in fact be using Promises) To be fair, fetch is the perfect example, though. Another one is animating and awaiting animation end with JS, or anything that needs to await browser rendering, if you want to avoid the setTimeout hack.

[@fatimanura6359]

JS tutorial from sir kevin powell!!??? No Way!!!, Thank you So much

[@MrTheoJ]

Absolute amazing tutorial

[@bbrixon]

My eyes are glazing over, but that's wonderful. This might get me to finally take some JS courses.

[@CheeseSteaksJimmy-g4l]

Wow this was super useful and explained in the best way

[@thecodeartisan]

Thank you for this video. As always, the BEST of the BEST.

[@thatgamingbrit]

good information generally only thing that i see missing is mention of the onRejected optional method you can pass in with the then. This can let you handle rejections when chaining promises to try and recover the flow instead of just breaking the chain outright. Very rarely used in the wild but its an option and can be useful super basic example. const somePromise = new Promise (doSomething) somePromise .then(handleResolve, handleRejected) .then(doSomeExtraStuff, handleRejected2) .then(doEvenMoreStuff, handleRejected3) .catch(somethingUnrecoverableHappened) .finally(cleanup)

[@capability-snob]

I appreciate that he says "a promise that something will happen" and not "a promise of a future value". Why? The motivation for promises was this: Alice sends a parts list to Bob and requests that when he is done, he send the bill to Carol in accounting. In a threaded environment, Alice would need to stand around twiddling her thumbs until Bob replied, and then she'd send the result to Carol. Promises are the fundamental unit of "when this completes, do that". I really liked Hallie's tutorial on promises, but the original is pretty good, too: Mark Miller's PhD thesis. Promises fit a lot better into the E programming language, used in the thesis, than they do in JavaScript, and E makes pretty clear what problems promises were designed to solve.

[@dealloc]

What you are describing is not unique to Promises. In fact, events and callbacks are suited for this type of non-blocking flow as well and is what was the _only_ way to do it before promises were introduced. But are not a deprecated way of dealing with asynchronous code. The introduction of promises were more of an technical one; to allow tasks with higher prioritisation than other tasks in the event loop. setTimeout and setInterval are examples of tasks that are created in a macro task queue, whereas promises are created within the micro task queue. If there are any tasks in the micro task queue, those will be executed before the next task in the macro task queue. Apart from nextTick from Node.js, promise callbacks will always be executed before other callbacks. This was also a time before async/await to block execution in a separate flow, while waiting for a promise to fulfil or reject. Previously you'd have to place your code depending on those results inside those callbacks.

[@capability-snob]

@@dealloc If you've followed the "prior art" links from the promises/a+ spec, you will note that none of the prior art matched the prioritisation given by the micro task queue. In fact, prioritisation was an open question in the previous "a spec". A+ included a fix to be specific that functions passed to then() do not execute immediately. So in fact, there was a lot of interest in promises, regardless of the priority of the enqueued tasks. If that was news to you, you might enjoy looking up the names in the credits of the spec. I mentioned Mark Miller, who had described in detail the specific semantics that made it into javascript way back in the 90s, but also Kris Kowal, who arguably did the first port to javascript from the original E description.

[@KB04]

Please, im begging, i hope you do more javascript videos when you have time.

[@Web-Dev-Codi]

Spelling promises

[@ideallyyours]

@@georgeliss4015 Sure, but a comment section with actual content discussion adds more value to the video than one pointing out silly mistakes.

[@DavidBrown-bs7gg]

He promises to fix it

[@Web-Dev-Codi]

@@ideallyyours we are just making sure he knows what's happening and I'm sure he appreciates the feedback.

[@rahmanmusah4470]

@@georgeliss4015😂😂😂😂

[@rahmanmusah4470]

@@DavidBrown-bs7ggI'm putting this comment in a museum 😂😂

[@friendly__drone9352]

Great video Kevin! (There's a slight typo in the title "Promsises")

[@dipakdayanand]

So, a promise object is created by passing a callback function and the arguments for the callback function are functions themselves ? Did I get it right ?

[@VladyslavHaidar]

What framework is Chris using for daily development?

[@adampielach4942]

Bright color mode is literally a felony

[@TheMetalMag]

I wish I had this video 2 years ago.. thanks

[@servertimeout8371]

dark mode please for code. it's too bright

[@playfulsparklestudio]

This is super useful, thank you 🙏❤️

[@LinhTran-om6qh]

One thing I'm still trying to wrap my head around is why the executor function can have access to resolve and reject method. I get that when creating a new promise, I need to pass an executor function. What I don't understand is why I have access to reject and resolve from the executor while I am the one who creates the executor itself? I know there are reject and resolve methods inside the promise constructor, and these two methods are passed to the executor as arguments at the end of the constructor and the executor gets executed immediately. But doesn't that mean I both provide the executor and also receive the executor from the constructor? It seems so circular to me...

[@elhamzeinodini4828]

Thanks for js content, it's as good as your css ones

[@MondisCrow]

This was excellent!

[@rajunaidu7751]

First I smoke this CSS and then I smoke this JavaScript

[@maikwolfram]

Thank u sooooooooo much for this channel !!!

[@adolfomartin5456]

Promise constructor is not new, it is a lot old. Async-await is sugar syntax for promises.

[@deatho0ne587]

What if a response should be JSON if 200, but if 204 or some other 200 series returns just a simple "string". I get how to do it, but might work for another video on top of this one. To be fair to the above what goes across the wire is never JSON.

[@alexandrmeyer]

wow, who is the guy and where is his channel?

[@nustaniel]

I like the "async function ()" declaration approach more since it also declares very clearly in your code that you are doing an asynchronous function. You don't need to look at the body of the function to understand and identify immediately that it is an async function. Also I guess JavaScript is going to Prom with its sises? (Original video title: JavaScript Promsises Crash Course)

[@prajapati_dp]

Well explained

[@k16e]

"Promises are weird"... JavaScript mimicking real life.

[@karima746]

excellent thank you

[@michaelgoddard4122]

Just starting JS so this is still above my pay scale.😢

[@mad_circuits]

My world is being destroyed. CSS god is doing JavaScript! The end is near!

[@lucassomething8653]

Is Chris like Arnold Schwarzenegger in Last action hero? Because he wears the same shirt in every film 😉

[@proteus1]

Off topic, but is there any easy work from home laptop jobs I caould do or learn as i want to get away from being tradesman. i KNOW HTML AND MODERATE CSS

[@27sosite73]

ty mate

[@Lonchanick]

nice!!!!

[@chumager]

pta mare... pensé que el tío Kevin iba a enseñar promesas, sólo quería reírme un rato :ó(

[@Steel0079]

Prom sises?

[@skygnd]

💀

[@galangel8287]

I wish you would go deeper, great video, but a bit basic

[@truthteachers]

Hi, all this simply because of Javascript being dysfunctional in the way it executes the code. Perhaps its a better time now that Javascript should be dumped and a new language structure to be created. Javascript is like an old Corvette adding on additional parts to make it look run like a Porche. Especially when they keep adding more junks like es6 and es2017. Very sloppy code.

[@skygnd]

Prom sis 💀

[@JosephCodette]

So sad to see to see you caved into doing JS videos , and not even done by you, which makes it even worse.

[@3dxspx703]

You're like, 5 yrs late with this topic sir.

[@rossclutterbuck1060]

Honestly, there was nothing wrong with XmlHttpRequest, and arguably Promise use more callbacks than the "callback hell" people cried about thinking XHR was bad. Async await is nice though.

[@philliplam2704]

Promises are 1999 wtf is wrong with you just use Async await Jesus

[@abhishekganapure6456]

kevin all the way 🫡👍