Really pushing the bar for programming content man. Thank you for these efforts. So hyped for the next generation of engineers who get to grow up with stuff like this 🙏
I've used all of these patterns at some point in the past, but never fully understood the pros and cons of each pattern. Your videos are always the most clear explanations. Thank you
I totally agree with Kevin! As a Java developer leaning more on JavaScript these days, this video and especially the concept of Inversion of Control and the way you present code we’re done excellently.
It is somehow heartwarming seeing an experienced dev saying that he could not understand something meanwhile i'm hitting myself everytime I can't wrap my head around
The first time I witnessed AJAX in action was on the Microsoft Developer Network web site circa 2000. It was being used to dynamically load expanded nodes in the table of contents. I remember calling over other devs to show them and we were all trying to wrap our heads around this sorcery. What a low key way to introduce such a revolutionary thing.
It seemed a little disingenuous that the Google executive talk about Gmail as maybe the first AJAX application when it was invented by Microsoft. Also I remember Google Maps rather than Gmail being the AJAX app that got everyone’s attention around 2004.
@@MarcStober Finding high quality clips from that era is difficult. So it's less "who do I give credit to" and more "who has a useful clip that fits the narrative".
I love the historical context presented in such a succinct way. Will definitely point all junior devs I come by to these videos to get their bearings on how we got here.
For additional historical context, referencing C# is good for paying respect to the language authors. They invented the async/await pattern and since then all languages have followed. It's truly a masterful pattern that joins together synchronous and asynchronous code
@@KalleJillheden JavaScript has always been a bit more … amateurish than others. E.g its Promise class has problems (e.g. cancelling is not part of the API), and having map/reduce as array functions is also silly (having them on the iterator would be easier to JIT compile and also enable using them without having to convert some array-like thing like a NodeList into an array first: `document.querySelectorAll(...).iter().map(...).filter(...).toArray()` ).
these videos are one of the best on the whole platform, can't wait for more. It's especially great for young devs, who don't know context of some things in the past that well.
This is one of the cases where C# was revolutionary. C# brought the async/await pattern (in 2012) almost 5 years before JavaScript implemented it (in 2017).
I get so confused learning JS man. Async is crazy for me rn… When I started digging in to async await a couple weeks ago I somehow found myself putting callbacks in my .then() functions. The other day I was writing Promise constructors inside async functions then trying to await them 😭😭 Learning JS I’ve found it’s less about syntax and more about concept. Knowing what you need and where. Videos like this help me organize these concepts so no matter the syntax I can always keep myself oriented in the code. For example, my end goal while learning async Js is to be able to refactor code from callbacks to async/await. Not through memorized syntax, but because I understand that success, failure callbacks turn in to resolve(), reject() and that the callback functions are turned to thenables. Same with going from Promise constructors to async/await. Sorry for long comment I’m an aspiring dev with no one to talk to about this stuff. Also if I said anything wrong please correct me. I need knowledge lol.
Couldn't agree more. It helps if you try to understand the bigger "Why" before you dive into the details of the syntax. Sounds like you've figured that out.
"my end goal while learning async Js is to be able to refactor code from callbacks to async/await." I had a good chuckle at that -- since I was doing exactly the same thing. ;o) I've been meaning to get back to that (hence the reason I'm watching the video). I got sidetracked with other goals, and it's always a struggle in finding that balance between how far you go to try to "make up for lost time" and moving on to newer things like JS frameworks (but still practicing vanilla JS in parallel). For example: I'm starting a 20-week React bootcamp today. I thought about taking it last year, but I just felt I wasn't ready (and I was still deciding whether to go with Angular or React). But over the last year, I worked on things like calculators and populating grid & filtering a table. Filtering by a field is easy -- but filtering by a combination of fields, lists, option groups, etc. -- is something else entirely. Granted, you could use a 3-party grid to eliminate the hassle, but the "hassle" is the whole point -- to make it as complex as possible as a learning tool. I've got a glitch or two to fix, and then I'm gonna polish it up -- but the essence of it all works. That personal project just happens to be COVID data using the link below. I'm not making commentary on COVID one way or the other -- it's just data that provides a real-life example for filtering: coronavirus-19-api.herokuapp.com/countries Anyway, if you're interested -- I have plenty of advice to pass along if you have some questions and would like some suggestions & resources for your learning approach. And since I'm trying to keep my JS goals moving along in parallel with others, helping someone out would help me as well (especially since you're focused on something of great interest to me). And once I get this grid cleaned up fully-code commented, you're welcome to fork it from github if you like (same goes for the calculator). Oh, and I still haven't made up my mind on Angular vs React -- I need more experience to make up my mind (and even then, I'll keep the door open). As a learning tool to help out in a job I had where they were using AngularJS and ASP.NET MVC, I developed a personal application using those platforms (with the goal of migrating to Angular later). But I'm no longer at that company because I chewed out my manager for his sloppy work, poor customer service, and turbo-charged ego. Other than that, he was a great guy who taught me a lot. Unfortunately, he wasn't so keen on listening to others. Anyhoo, for various reasons -- I opted to go the React direction for now (with the aim of returning to Angular later so I can compare). And the bootcamp is a way to keep me on track (same goes for offering my help to you). For example: In preparing for that bootcamp, I bought a $39 course -- but instead of simply trying to plow through it, I paused after a couple of sections to practice what I've learned. I found these exercises that have been ideal for that purpose: coderfiles.dev/blog/reactjs-coding-exercises/ I'm not suggesting you start doing React (or any framework) right now -- just giving you some ideas for how you approach your goals.
tbh before this video I had the opposite and wrong idea of async await. Async+await is forcing the execution to behave synchronously i.e. one after the other. All that and without blocking the whole browser. I guess the keywords turned out to be a bit misleading for me till now.
Damn man, you deserve yourself a hard-earned sub. Really appreciate the effort you put into these details which provides the perfect amount of detail. You're the "programmer historian" channel I've been looking for.
Amazing content as always. I just love how it is still referred to as AJAX when mostly there's no XML to be found. One older dev I talked to simply used to call JSON XML until I corrected him. I guess it's really hard for older devs to keep track of all the changes in the front-end world.
I'm learning JS at the moment, only getting started with the async part of it. And this is just the video I needed. Everything makes so much more sense. Thanks a lot for this. Liked and subbed.
Haven't seriously done web dev in 13 years and let me tell you, it's a completely different ball game now. I barely recognize JavaScript along with my outdated HTML and CSS. I don't miss it though, it was a horrible mess before and Internet Explorer 6 is no longer anyone's worry. Good job to everyone involved in pushing the technology further and thank you for this brief summary of something big that I missed.
I adore the story telling and the occasional memes. Almost everything that's new is built upon something existing and I absolutely love the fact that you provide the whole journey of a feature, that context helps clear the abstraction with a lot of new tech that we just use without really understanding the depths of it and why should we use it.
More of these docs! As a web dev cutting my teeth in the modern era, where most things are abstracted away from you, context of where these technologies came from is invaluable.
Another awesome video! Can really tell the incredible amount of time you put into this episode🔥 my main question to myself after watching was should I go to Denny’s? 🥞🍳
Fantastic video! Great examples that you provide along the way, very easy to follow and grasp while you at the same time maintain a good pace. Already looking forward to your next video! :)
Nice video! JS has a reputation for having many weird quirks, but this video just shows that with a great team behind it, a language can improve and fix some of the problems of past design. Can't wait to see what other features will be added in the future!
Love this style of video, really helps get the context and a better understanding of the reason behind different kind of implementations. Hopefully you will continue this series.
This video just showed up in my timeline and even though I was fairly certain I'd know all the information, but I clicked on it anyway because I'm always curious to hear what "new" voices are saying in the dev community. I was very impressed with the video production and the concise and precise explanations and thought to myself, "who is this guy." I then saw the "tylermcginnis" in the getuser example, and thought "ah yes, this all checks out." Keep making stuff Tyler! You've already had a massively positive impact on my career growth as a SWE, and I'm excited to see you're now on TH-cam, making your content more broadly accessible to the wider community! 👍
The one thing that JavaScript is still missing natively is the ability to handle asynchronous streams of data, which means an external library like RxJS is needed to make doing this manageable.
Fun video. One point I’d add is that async/await is built on-top of the same Promise API. Every async function returns a promise; and likewise, await operates on a promise. It’s actually possible to implement async/await-like behavior using generator functions and some glue logic to connect the Promise API-making async/await a kind of syntactic sugar.
That’s sort of how Python does it. Promises/futures and the event loop are just part of the standard library (asyncio), implementable in pure Python, rather than being part of the core language.
Wish I had this video a few months ago when I was first really trying to learn about promised and async await functions in JavaScript. This video explained everything I miss understood and had to trial an error to get, as well as neatly condensed everything I did understand from probably 5-10 videos of much longer length. Can’t wait to see more content from you and definitely plan to check out your other videos
Well thought out video, another (probably opinionated) view is that as a result of moving towards async await in javascript is that it starts to behave more like typed languages i.e. C# in which try catch is a reasonably similar thing to use with asynchronous code. Thus making it easier for devs to dabble in both language and barrier to entry to either one of the two could potentially be smaller if you already know one of the two
try-catch is for exceptions, which JavaScript also has. But that’s an entirely separate thing. async/await is the resurgence of a very old CS concept called _coroutines_ , which are basically a way of avoiding threading. It’s become popular in many languages now, including Python with its asyncio framework.
It's important to note that the downside of "await" is that it completely blocks the thread If you find yourself needing to call two or more Promises that do not depend on each other, you better off: const [value1, value2] = await Promise.all([promise1, promise2]);
True but a language in itself cannot determine the existence of or lack of dependency so dealing with it is left to the programmer. This is why in C# the mixing of async with the TPL is a developer choice to be tailored to the problem at hand.
But wait! There is more down that rabbit hole. - Use Promise.all if you need multiple promises to resolve successfully before proceeding and treat any rejected promise by immediately returning a rejection at the top level. - Use Promise.allSettled to wait for promises to either resolve or reject. This never rejects at the top level. It resolves to an array of {status, value} objects, so you can check the status of each promise and handle the outcomes. - Use Promise.any if you can proceed as soon as one of the promises succeeds. This will reject at the top level if all individual promises are rejected. - Use Promise.race to proceed as soon as the first promise resolves or rejects. This will resolve or reject depending on the outcome of the first settled promise.
I don't know... Why don't catch errors where it occured? The gigantic catch block where all exceptions fall in, and you don't know what caused the problem never made sense to me...
@@uidotdev Ye, but what's the point then... Await takes away the async nature of the calls and blocks instead. It's not an evolved way to write code, just a possibility to avoid dealing with Promises if we don't need asynchronity. Prqctically it just turns a Promise into a function call as if it were ended with a while (!completed) continue; wait loop. If you really need asynchronity in the callee, you still have to write .then() calls.
...and catching the error in the Promise in the first await will not trigger a higher level try/catch block, so it will not jump out of the execution of the block and continues with the second await call. This is usually not what one wants, when the calls depend on each other. In my opinion the .then() syntax does not decrase readability making harder to follow. Rather the opposite: it clearly signifies dependency, it is seen when something will be executed in the chain, you can see that there is a dependency chain even, not just a series of function calls below each other.
your videos are amazing and professional, it's a shame that some newer generation of "programmers" are learning e.g. react without even understanding fundamentals. i hope your channel get a lot more attention.
I always found promise to be a freaking mess, and I was always like "bruh, why don't just do async/await already, duuuuh." hehe they finally got the message :p
Promises are just Tasks from the .Net Task Parallel Library, and async/await are from C#, utilizing them the same way. Microsoft was on the committee, obviously. ;)
Await is almost as powerful as continuation passing. And it's just amazing for readability, from inside it looks like a simple callback to fill the missing bits, but from outside you can use the implemented parts as if THEY were simple calls. So by this turning-a-call-into-a-hidden-return you can stitch control flows together with unprecedented freedom, while maintaining full readability and modularity.
9:07 The issue isn’t the difficulty of adding new features to JavaScript, it has more to do with the overhead of those features. Here we want to add a coroutine feature. The traditional way coroutines were implemented allows preemption to occur inside any function call. This means each coroutine “thread” needs its own full stack, just like you have with multithreading. This is called “stackful” coroutines. The way JavaScript, Python and other languages do it, with the async/await keywords, is called “stackless”. What that really means is, because preemption can only occur on explicit “await” calls, and these are only allowed in the bodies of “async” functions, only a small amount of stack data needs to be switched when preemption happens.
Try/catch towers of hell are also a thing. I think knowing all three patterns is a must. For example, code that is not sequential, but rather forks, might be better encapsulated inside an API, which takes callbacks for each possible fork, of course that it self has its issues, though it applies only for certain cases, but at least it helps keeping things declarative without creating special return types for every fork.
I almost exclusively use .then and .catch when working with promises. In fact it always felt like "dirty" code to me whenever I saw async await. This was really good to see how someone would use async/await in a way that increases simplicity and "cleanliness".
Really pushing the bar for programming content man. Thank you for these efforts. So hyped for the next generation of engineers who get to grow up with stuff like this 🙏
❤️
Dying from possibilities and amount of things to learn but we are crawling up 😂
The phone number vs. buzzer analogy is the best explanation I’ve ever seen on this topic
Thank you!
I've used all of these patterns at some point in the past, but never fully understood the pros and cons of each pattern. Your videos are always the most clear explanations. Thank you
Thank you Kevin! Glad it was helpful.
I totally agree with Kevin! As a Java developer leaning more on JavaScript these days, this video and especially the concept of Inversion of Control and the way you present code we’re done excellently.
It is somehow heartwarming seeing an experienced dev saying that he could not understand something meanwhile i'm hitting myself everytime I can't wrap my head around
Wow that buzzer/phone example was a stellar analogy for promise/callback
Thank you! Glad it was helpful.
The first time I witnessed AJAX in action was on the Microsoft Developer Network web site circa 2000. It was being used to dynamically load expanded nodes in the table of contents. I remember calling over other devs to show them and we were all trying to wrap our heads around this sorcery. What a low key way to introduce such a revolutionary thing.
Had to be one of the earliest use cases. Great story. Thanks for sharing!
@@uidotdev Before that, IE 5.0 had the original implementation in MSXML, late 1990s.
@@robslaney3729 I remember that. Data islands. IE supported tag that would be loaded with (surprise) xml
It seemed a little disingenuous that the Google executive talk about Gmail as maybe the first AJAX application when it was invented by Microsoft. Also I remember Google Maps rather than Gmail being the AJAX app that got everyone’s attention around 2004.
@@MarcStober Finding high quality clips from that era is difficult. So it's less "who do I give credit to" and more "who has a useful clip that fits the narrative".
I love the historical context presented in such a succinct way. Will definitely point all junior devs I come by to these videos to get their bearings on how we got here.
Means a lot. Thanks Terence!
For additional historical context, referencing C# is good for paying respect to the language authors. They invented the async/await pattern and since then all languages have followed. It's truly a masterful pattern that joins together synchronous and asynchronous code
@@KalleJillheden JavaScript has always been a bit more … amateurish than others. E.g its Promise class has problems (e.g. cancelling is not part of the API), and having map/reduce as array functions is also silly (having them on the iterator would be easier to JIT compile and also enable using them without having to convert some array-like thing like a NodeList into an array first: `document.querySelectorAll(...).iter().map(...).filter(...).toArray()` ).
these videos are one of the best on the whole platform, can't wait for more. It's especially great for young devs, who don't know context of some things in the past that well.
Thanks so much. Means a lot.
This is one of the cases where C# was revolutionary. C# brought the async/await pattern (in 2012) almost 5 years before JavaScript implemented it (in 2017).
problem is the single threaded event loop of JS makes the behavior wildly different between C# and JS.
Nah, F# had it in 2007; but it's really just a specialization of the do-notation in Haskell which has been around since 1998
Holy crap, this was the clearest, most concise explanation I've found for this topic. 10/10.
So glad it was helpful. Thanks for watching!
This is the best explanation of async/await. I always struggled in understanding it fully. Thanks for this amazing informative video
Glad it was helpful!
I get so confused learning JS man. Async is crazy for me rn… When I started digging in to async await a couple weeks ago I somehow found myself putting callbacks in my .then() functions. The other day I was writing Promise constructors inside async functions then trying to await them 😭😭
Learning JS I’ve found it’s less about syntax and more about concept. Knowing what you need and where. Videos like this help me organize these concepts so no matter the syntax I can always keep myself oriented in the code.
For example, my end goal while learning async Js is to be able to refactor code from callbacks to async/await. Not through memorized syntax, but because I understand that success, failure callbacks turn in to resolve(), reject() and that the callback functions are turned to thenables. Same with going from Promise constructors to async/await.
Sorry for long comment I’m an aspiring dev with no one to talk to about this stuff. Also if I said anything wrong please correct me. I need knowledge lol.
Couldn't agree more. It helps if you try to understand the bigger "Why" before you dive into the details of the syntax. Sounds like you've figured that out.
Hey friend. Keep up the good work! I wish you the best :)
"my end goal while learning async Js is to be able to refactor code from callbacks to async/await." I had a good chuckle at that -- since I was doing exactly the same thing. ;o) I've been meaning to get back to that (hence the reason I'm watching the video). I got sidetracked with other goals, and it's always a struggle in finding that balance between how far you go to try to "make up for lost time" and moving on to newer things like JS frameworks (but still practicing vanilla JS in parallel).
For example: I'm starting a 20-week React bootcamp today. I thought about taking it last year, but I just felt I wasn't ready (and I was still deciding whether to go with Angular or React). But over the last year, I worked on things like calculators and populating grid & filtering a table. Filtering by a field is easy -- but filtering by a combination of fields, lists, option groups, etc. -- is something else entirely. Granted, you could use a 3-party grid to eliminate the hassle, but the "hassle" is the whole point -- to make it as complex as possible as a learning tool.
I've got a glitch or two to fix, and then I'm gonna polish it up -- but the essence of it all works. That personal project just happens to be COVID data using the link below. I'm not making commentary on COVID one way or the other -- it's just data that provides a real-life example for filtering: coronavirus-19-api.herokuapp.com/countries
Anyway, if you're interested -- I have plenty of advice to pass along if you have some questions and would like some suggestions & resources for your learning approach. And since I'm trying to keep my JS goals moving along in parallel with others, helping someone out would help me as well (especially since you're focused on something of great interest to me). And once I get this grid cleaned up fully-code commented, you're welcome to fork it from github if you like (same goes for the calculator).
Oh, and I still haven't made up my mind on Angular vs React -- I need more experience to make up my mind (and even then, I'll keep the door open). As a learning tool to help out in a job I had where they were using AngularJS and ASP.NET MVC, I developed a personal application using those platforms (with the goal of migrating to Angular later). But I'm no longer at that company because I chewed out my manager for his sloppy work, poor customer service, and turbo-charged ego. Other than that, he was a great guy who taught me a lot. Unfortunately, he wasn't so keen on listening to others.
Anyhoo, for various reasons -- I opted to go the React direction for now (with the aim of returning to Angular later so I can compare). And the bootcamp is a way to keep me on track (same goes for offering my help to you).
For example: In preparing for that bootcamp, I bought a $39 course -- but instead of simply trying to plow through it, I paused after a couple of sections to practice what I've learned. I found these exercises that have been ideal for that purpose:
coderfiles.dev/blog/reactjs-coding-exercises/
I'm not suggesting you start doing React (or any framework) right now -- just giving you some ideas for how you approach your goals.
Old Async code drives me crazy bro lol. I'm still trying to wrap my head around it.
tbh before this video I had the opposite and wrong idea of async await. Async+await is forcing the execution to behave synchronously i.e. one after the other. All that and without blocking the whole browser. I guess the keywords turned out to be a bit misleading for me till now.
I'm pretty confident with async Javascript but this was a great history and refresher. Well explained Tyler!
Thank you Francis! Glad you enjoyed it.
These “The Story of” videos are pure gold.
Thanks Stephen!
Beautiful explanation, probably the most clear and extensively explained example on this I have seen
Thanks for the kind words ❤️
you always deliver awesome content
Thank you!
These are some high quality videos, happy the algorithm recommended this channel
Thank you!
This channel will blow up. Glad I found you early. Exceptional information and love your point of view on this kind of stuff.
Thank you so much for the kind words ❤️
Damn man, you deserve yourself a hard-earned sub. Really appreciate the effort you put into these details which provides the perfect amount of detail. You're the "programmer historian" channel I've been looking for.
Thank so much Benji!
🟡Wonderful hindsight and clear vision of technological advances.
Thank you!
The simplicity and depth of these tutorials are second to none.
Congratulations on the channel!
Amazing content as always.
I just love how it is still referred to as AJAX when mostly there's no XML to be found. One older dev I talked to simply used to call JSON XML until I corrected him. I guess it's really hard for older devs to keep track of all the changes in the front-end world.
Ironically, it's also hard for new devs to get why things are done they way they are (specifically around weird naming conventions).
@@uidotdev yeah, some weird stuff exist for historical reasons, or because of mathematicians! :P
That's the best video on promises I have seen so far
Thank you!
I'm learning JS at the moment, only getting started with the async part of it. And this is just the video I needed. Everything makes so much more sense. Thanks a lot for this. Liked and subbed.
Glad it was helpful!
this is the best channel I've came across , thank you god 💘
Thanks for watching!
Haven't seriously done web dev in 13 years and let me tell you, it's a completely different ball game now. I barely recognize JavaScript along with my outdated HTML and CSS. I don't miss it though, it was a horrible mess before and Internet Explorer 6 is no longer anyone's worry. Good job to everyone involved in pushing the technology further and thank you for this brief summary of something big that I missed.
I adore the story telling and the occasional memes. Almost everything that's new is built upon something existing and I absolutely love the fact that you provide the whole journey of a feature, that context helps clear the abstraction with a lot of new tech that we just use without really understanding the depths of it and why should we use it.
So glad it was helpful. Thanks for watching!
This is the most incredibly entertaining programming video I've ever seen
Glad you enjoyed it!
More of these docs! As a web dev cutting my teeth in the modern era, where most things are abstracted away from you, context of where these technologies came from is invaluable.
I'd be glad to see a sequel of this explaining the glory of Observables.
Great video! Always great to learn how one tool came to existence and what is the reason behind its existence.
Thank you!
Another awesome video! Can really tell the incredible amount of time you put into this episode🔥
my main question to myself after watching was should I go to Denny’s? 🥞🍳
Thank you Harry! My only goal in life is to get restaurants to sponsor me for these. Imagine the possibilities.
@@uidotdev I fully support your life goals!
why is more important to me when learning new things and thanks for this.
Agree!
This is a phenomenal "Tutorial" history lesson!
So glad you enjoyed it!
Fantastic video! Great examples that you provide along the way, very easy to follow and grasp while you at the same time maintain a good pace.
Already looking forward to your next video! :)
Thanks for watching!
The restaurant analogy is helpful for understanding inversion of control. Thanks.
Glad it helped!
Nice video! JS has a reputation for having many weird quirks, but this video just shows that with a great team behind it, a language can improve and fix some of the problems of past design. Can't wait to see what other features will be added in the future!
I agree!
This felt like a movie, great video!
Thanks for watching!
This is the best explanation of asynchronous code I've ever seen!
Love this style of video, really helps get the context and a better understanding of the reason behind different kind of implementations. Hopefully you will continue this series.
Glad you enjoyed it!
This video just showed up in my timeline and even though I was fairly certain I'd know all the information, but I clicked on it anyway because I'm always curious to hear what "new" voices are saying in the dev community. I was very impressed with the video production and the concise and precise explanations and thought to myself, "who is this guy." I then saw the "tylermcginnis" in the getuser example, and thought "ah yes, this all checks out."
Keep making stuff Tyler! You've already had a massively positive impact on my career growth as a SWE, and I'm excited to see you're now on TH-cam, making your content more broadly accessible to the wider community! 👍
I always love comments like these. Thank you so much for all the support throughout the years. Glad I could be helpful! ❤️
wasn't the first version of Outlook for the Web - a XHR dynamic desktop app like site?
This was a damn good visual and conceptual analogy of Promises. Hats off to you sir.
Thank you!
The one thing that JavaScript is still missing natively is the ability to handle asynchronous streams of data, which means an external library like RxJS is needed to make doing this manageable.
The RxJS people have been in full force in the comments 😅
could you state an example for handling asynchronous streams of data?
@@pizzapanni WebSocket connections
@@cinnanyan look at for await you can use that with a generator that is fed by the websocket messages.
JS Dev: Call me back when you get the chance
Date: No promises
😩😩😩
Fun video. One point I’d add is that async/await is built on-top of the same Promise API. Every async function returns a promise; and likewise, await operates on a promise. It’s actually possible to implement async/await-like behavior using generator functions and some glue logic to connect the Promise API-making async/await a kind of syntactic sugar.
That’s sort of how Python does it. Promises/futures and the event loop are just part of the standard library (asyncio), implementable in pure Python, rather than being part of the core language.
Such a phenomenal channel! Keep up the great work...
❤️
Amazing video man! I can't believe I've been missing such great content. Thank you 🙏🏾🙏🏾
So glad you enjoyed it!
100 for creativity , and 100 for content , thank you
This is a brilliant video, uidotdev. Great job mate.
Thank you! Means a lot.
Outstanding man. THIS is the type of coding content I've been looking for. Absolutely destroying the like button on this one.
Ayy thank you!
i already used this in my capstone project and because of that i graduated BSIT college
now im continue to learn
Please continue making such videos , they're great
We definitely will. Thanks for watching!
For a guy who learned JS only from Async / Await - this is fucking amazing!
Thank you!
Wish I had this video a few months ago when I was first really trying to learn about promised and async await functions in JavaScript. This video explained everything I miss understood and had to trial an error to get, as well as neatly condensed everything I did understand from probably 5-10 videos of much longer length. Can’t wait to see more content from you and definitely plan to check out your other videos
So glad it was helpful!
Very well executed video! Keep up the good work. I just subscribed!
Thank you!
Well thought out video, another (probably opinionated) view is that as a result of moving towards async await in javascript is that it starts to behave more like typed languages i.e. C# in which try catch is a reasonably similar thing to use with asynchronous code. Thus making it easier for devs to dabble in both language and barrier to entry to either one of the two could potentially be smaller if you already know one of the two
Great comment. Thanks for watching!
try-catch is for exceptions, which JavaScript also has. But that’s an entirely separate thing.
async/await is the resurgence of a very old CS concept called _coroutines_ , which are basically a way of avoiding threading. It’s become popular in many languages now, including Python with its asyncio framework.
It's important to note that the downside of "await" is that it completely blocks the thread
If you find yourself needing to call two or more Promises that do not depend on each other, you better off:
const [value1, value2] = await Promise.all([promise1, promise2]);
That's a really good remark. Thanks for sharing it
👍
True but a language in itself cannot determine the existence of or lack of dependency so dealing with it is left to the programmer. This is why in C# the mixing of async with the TPL is a developer choice to be tailored to the problem at hand.
But wait! There is more down that rabbit hole.
- Use Promise.all if you need multiple promises to resolve successfully before proceeding and treat any rejected promise by immediately returning a rejection at the top level.
- Use Promise.allSettled to wait for promises to either resolve or reject. This never rejects at the top level. It resolves to an array of {status, value} objects, so you can check the status of each promise and handle the outcomes.
- Use Promise.any if you can proceed as soon as one of the promises succeeds. This will reject at the top level if all individual promises are rejected.
- Use Promise.race to proceed as soon as the first promise resolves or rejects. This will resolve or reject depending on the outcome of the first settled promise.
Here before 100k, i love these history / explanatory videos
Ayyy ❤️❤️❤️
That is some great content. You surely deserve many more subs and views! Looking forward to more videos!
❤️
Great video. Super easy to follow and very informative while also being engaging.
Thank you!
Extremely clear explanations, subscribed !
This is actually interesting not just for js but super well made,
Thanks. So good that I’m watching again to absorb
Thank you!
I have never thought of Promises as eliminating inversion of control, pretty cool detail!
Amazing content, informative as well as entertaining. Your analogies are on point.
Much appreciated!
Man those examples are amazing.... very clear...
Thanks for watching!
I'm so glad I found this channel!
subbing.. that promise analogy was amazing.
Thank you!
Excellent content. Thank you. 🙏
Thanks for watching!
I'm a backend dev only learning about these amazing and powerful tools. It's pretty great
Glad you enjoyed it!
Oi, where was this 3 years ago when I needed it 😭
Thanks for watching!
First time I hear a valid argument for async/await over .then() / .catch()... Thank you!
Glad you enjoyed it!
I don't know... Why don't catch errors where it occured? The gigantic catch block where all exceptions fall in, and you don't know what caused the problem never made sense to me...
@@gabiold You can still use .catch on individual await calls if you want (since they return a promise).
@@uidotdev Ye, but what's the point then... Await takes away the async nature of the calls and blocks instead. It's not an evolved way to write code, just a possibility to avoid dealing with Promises if we don't need asynchronity.
Prqctically it just turns a Promise into a function call as if it were ended with a
while (!completed) continue;
wait loop.
If you really need asynchronity in the callee, you still have to write .then() calls.
...and catching the error in the Promise in the first await will not trigger a higher level try/catch block, so it will not jump out of the execution of the block and continues with the second await call.
This is usually not what one wants, when the calls depend on each other.
In my opinion the .then() syntax does not decrase readability making harder to follow. Rather the opposite: it clearly signifies dependency, it is seen when something will be executed in the chain, you can see that there is a dependency chain even, not just a series of function calls below each other.
This is awesome! Defo saving this for later.
Thank you!
The explanation is beautiful, you've earned a new sub 👍
Welcome!
keeping making this kind of videos and also try to make another kind of videos too. So that I dont get bored.
your videos are amazing and professional, it's a shame that some newer generation of "programmers" are learning e.g. react without even understanding fundamentals. i hope your channel get a lot more attention.
Thank you!
I always found promise to be a freaking mess, and I was always like "bruh, why don't just do async/await already, duuuuh." hehe they finally got the message :p
Thanks for watching!
Excellent explanation!
Thanks for watching!
Simply remarkable! 😍
Thanks for watching!
this is the best explanation out there 💯👌
Thank you!
Fantastic work
Thank you!
i misread 52k subs as 520k subs lol. underrated channel
One day!
Great vídeo! Saved as part of my theory material. Subscribed
These videos are on another level! I wonder how much time it takes per video to make it so slick?
This one was 3 weeks of ~50 hour weeks.
@@uidotdev 😲 Thanks a lot for taking all that pain for the quality content 🙌🏽
I'm sticking with transition-less animations on my channel for now 🙈
Promises are just Tasks from the .Net Task Parallel Library, and async/await are from C#, utilizing them the same way. Microsoft was on the committee, obviously. ;)
Simply amazing!
Thank you!
Loving this series!
Thanks for watching!
JS is very easy... until you hear about this stuff. Good thing we got this video
async...await may look like they blocking the main execution thread but they're just syntactic sugars for promise chaining.
Great video like always, give us some more! :)
Working on it! ❤️
@@uidotdev I have no doubt, a big greeting from Serbia and just keep it up! :)
You deserve my subscription for this!!
Welcome!
Await is almost as powerful as continuation passing. And it's just amazing for readability, from inside it looks like a simple callback to fill the missing bits, but from outside you can use the implemented parts as if THEY were simple calls. So by this turning-a-call-into-a-hidden-return you can stitch control flows together with unprecedented freedom, while maintaining full readability and modularity.
Great comment. Thanks for watching!
9:07 The issue isn’t the difficulty of adding new features to JavaScript, it has more to do with the overhead of those features. Here we want to add a coroutine feature. The traditional way coroutines were implemented allows preemption to occur inside any function call. This means each coroutine “thread” needs its own full stack, just like you have with multithreading. This is called “stackful” coroutines.
The way JavaScript, Python and other languages do it, with the async/await keywords, is called “stackless”. What that really means is, because preemption can only occur on explicit “await” calls, and these are only allowed in the bodies of “async” functions, only a small amount of stack data needs to be switched when preemption happens.
goddamn his voice is super pleasing to hear
Thank you!
Try/catch towers of hell are also a thing.
I think knowing all three patterns is a must.
For example, code that is not sequential, but rather forks, might be better encapsulated inside an API, which takes callbacks for each possible fork, of course that it self has its issues, though it applies only for certain cases, but at least it helps keeping things declarative without creating special return types for every fork.
I agree!
👨💻👌 awesome video bro
Thank you!
Fireship style loving it!
Jeff is the 🐐
This is a gem.
Thank you!
Great video :) I would add information about the generator function that is used by async function under the hood
Thanks for watching! Debated that but ended up keeping it out.
another banger from uidotdev
❤️
Great content! Just subscribed!
I almost exclusively use .then and .catch when working with promises. In fact it always felt like "dirty" code to me whenever I saw async await. This was really good to see how someone would use async/await in a way that increases simplicity and "cleanliness".
Thank you!
Keep posting more videos 😀
Working on it!