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".
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.
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()` ).
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? 🥞🍳
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.
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.
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.
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 RUclips, 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.
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'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.
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!
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.
3:32 : "It's this second use case that is the more interesting one" Functional programmers will not be taking this shot against function abstraction lightly ;)
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
i use callbacks. it starts out as a pyramid and when it gets too wide you cut the top off and name it elsewhere, then its a spaceship with laser guns. inversion of control falls under the realm of 'useless garbage didnt ask dont care'. the ad hominem that follows is 'when software gets changed it can break' and so I truly don't see the problem at 4:05 nor what promises aim to solve. heck, a success callback is often null just because you may have nothing to do afterwards. 'callbacks force you out of your way of thinking' is a cope. thats your way of thinking. grow beyond it. subscribed
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.
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. ;)
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.
In the .NET world, once you get your head around Async programming, its often easier to just write every function as Async by default because in most cases the Async code will make more efficient use of threads and CPU cores.. It would be nice if Javascript teachers and programmers just adopted Async as the default way of doing things. That way code maintainers wouldn't have to waste so much time and effort figuring out what a particular piece of code is supposed to do just so that they can make the tiny code change they are asked to do without breaking the entire thing. Deeply nested functions and long function chains are an absolute nightmare to deal with.
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.
Can we just fast forward 3 years to when the React community has realized that declarative async code is a good idea? I haven't written async/await a single time outside of my React projects, and never will. FRP FTW.
@@uidotdev the learning curve of FRP is identical to the learning curve of writing async code declaratively. It's more a matter of changing mindset and habits than it is about learning 30 different APIs or anything like that. And every bit of it has a solid return on investment. 1st step: Stop writing callback functions. Callback functions are little boxes for feature logic that should be collocated with the features themselves. Redux is FRP at one layer.
Another thing you didn't mention is promise joining. 2 functions return 2 promises and you want to chain them in one promise. There is the promise.all approach but it might not suit your need so you switch to returning a promise inside .then callbacks but now you recreated the callback hell with promises. If any of you who is reading my comment fell for this problem, the simplest solution I can think of is using await like the dude in the video did. DO NOT over promisify stuff, only use promises when you have a reason to make the task asynchronus. If you're a library developer, provide a "yourlib/promises" folder in your package that has the promisified version of your library
I will never understand "AJAX". It's such utter bullshit. I don't need anything called ajax to update my website with data from the server. What is this nonsense...
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.
RxJs seems complicated at the start but once you grok it you will never reach for a promise again. RxJs really is the best UI technology to come out in years, you just need to start thinking reactively.
The way of your explanation is really good and I understand the concepts well but the meme/joke videos are too long and distracting... Great video nonetheless.
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 😂
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
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".
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.
The phone number vs. buzzer analogy is the best explanation I’ve ever seen on this topic
Thank you!
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
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.
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!
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()` ).
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!
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.
Beautiful explanation, probably the most clear and extensively explained example on this I have seen
Thanks for the kind words ❤️
These “The Story of” videos are pure gold.
Thanks Stephen!
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.
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!
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
JS Dev: Call me back when you get the chance
Date: No promises
😩😩😩
This is the most incredibly entertaining programming video I've ever seen
Glad you enjoyed it!
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.
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 RUclips, 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?
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.
This felt like a movie, great video!
Thanks for watching!
Here before 100k, i love these history / explanatory videos
Ayyy ❤️❤️❤️
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.
you always deliver awesome content
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 a phenomenal "Tutorial" history lesson!
So glad you enjoyed it!
This is actually interesting not just for js but super well made,
Thanks. So good that I’m watching again to absorb
Thank you!
100 for creativity , and 100 for content , thank you
This is the best explanation of asynchronous code I've ever seen!
This is awesome! Defo saving this for later.
Thank you!
The restaurant analogy is helpful for understanding inversion of control. Thanks.
Glad it helped!
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 meme clips you choose are next level
Thank you!
Man those examples are amazing.... very clear...
Thanks for watching!
That is some great content. You surely deserve many more subs and views! Looking forward to more videos!
❤️
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 🙈
Great video! Always great to learn how one tool came to existence and what is the reason behind its existence.
Thank you!
goddamn his voice is super pleasing to hear
Thank you!
The explanation is beautiful, you've earned a new sub 👍
Welcome!
i misread 52k subs as 520k subs lol. underrated channel
One day!
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!
Very well executed video! Keep up the good work. I just subscribed!
Thank you!
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!
this is the best explanation out there 💯👌
Thank you!
async...await may look like they blocking the main execution thread but they're just syntactic sugars for promise chaining.
3:32 : "It's this second use case that is the more interesting one"
Functional programmers will not be taking this shot against function abstraction lightly ;)
Fair fair. That line was just the setup for the rest of the video.
Wow that buzzer/phone example was a stellar analogy for promise/callback
Thank you! Glad it was helpful.
JS is very easy... until you hear about this stuff. Good thing we got this video
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!
0:08 Remember, everyone was a beginner once ☺
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 ❤️
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! :)
Amazing!
❤️
i use callbacks. it starts out as a pyramid and when it gets too wide you cut the top off and name it elsewhere, then its a spaceship with laser guns.
inversion of control falls under the realm of 'useless garbage didnt ask dont care'. the ad hominem that follows is 'when software gets changed it can break'
and so I truly don't see the problem at 4:05 nor what promises aim to solve. heck, a success callback is often null just because you may have nothing to do afterwards.
'callbacks force you out of your way of thinking' is a cope. thats your way of thinking. grow beyond it.
subscribed
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.
loving the video
Thanks for watching!
Promise.all() is still very useful and can be more convenient and robust than async-await
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. ;)
I really like using
await new Promise(requestAnimationFrame);
It works wonders.
For a guy who learned JS only from Async / Await - this is fucking amazing!
Thank you!
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!
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.
amazing
Thank you!
🟡Wonderful hindsight and clear vision of technological advances.
Thank you!
In the .NET world, once you get your head around Async programming, its often easier to just write every function as Async by default because in most cases the Async code will make more efficient use of threads and CPU cores..
It would be nice if Javascript teachers and programmers just adopted Async as the default way of doing things. That way code maintainers wouldn't have to waste so much time and effort figuring out what a particular piece of code is supposed to do just so that they can make the tiny code change they are asked to do without breaking the entire thing.
Deeply nested functions and long function chains are an absolute nightmare to deal with.
i already used this in my capstone project and because of that i graduated BSIT college
now im continue to learn
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.
Man you gotta make a video on how you animate this code in the presentation 🔥
another banger from uidotdev
❤️
why is more important to me when learning new things and thanks for this.
Agree!
Keep posting more videos 😀
Working on it!
this is the best channel I've came across , thank you god 💘
Thanks for watching!
keeping making this kind of videos and also try to make another kind of videos too. So that I dont get bored.
What a great video!
I'd be glad to see a sequel of this explaining the glory of Observables.
Watching at 0.75x.
7:55 so the reason we ended up with async await syntax is because chaining can make it hard to get state further down the chain.
Can we just fast forward 3 years to when the React community has realized that declarative async code is a good idea? I haven't written async/await a single time outside of my React projects, and never will. FRP FTW.
FRP is great. The learning curve.. not so much.
@@uidotdev the learning curve of FRP is identical to the learning curve of writing async code declaratively. It's more a matter of changing mindset and habits than it is about learning 30 different APIs or anything like that. And every bit of it has a solid return on investment. 1st step: Stop writing callback functions. Callback functions are little boxes for feature logic that should be collocated with the features themselves. Redux is FRP at one layer.
That's the best video on promises I have seen so far
Thank you!
Amazing content!
Another thing you didn't mention is promise joining. 2 functions return 2 promises and you want to chain them in one promise. There is the promise.all approach but it might not suit your need so you switch to returning a promise inside .then callbacks but now you recreated the callback hell with promises. If any of you who is reading my comment fell for this problem, the simplest solution I can think of is using await like the dude in the video did. DO NOT over promisify stuff, only use promises when you have a reason to make the task asynchronus. If you're a library developer, provide a "yourlib/promises" folder in your package that has the promisified version of your library
Correct. It's hard to get the entire API into videos like this.
I like your content :-)
I like you!
Do function currying please!
Great idea!
I will never understand "AJAX". It's such utter bullshit. I don't need anything called ajax to update my website with data from the server. What is this nonsense...
🤔
I loved the Tommy Tutone callback in your example. Eh?... callback ... see what I did there? Jokes.🤓
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!
Please continue making such videos , they're great
We definitely will. Thanks for watching!
How do observables tie into this?
Great question. That would make a fun add on vid.
Keep it up! 😃
Thanks for watching!
@@uidotdev Pleasure!
This is a brilliant video, uidotdev. Great job mate.
Thank you! Means a lot.
Yeah, today is Monday
Thanks
if only i could use the beautiful simplicity of async/await and promises instead of the obnoxious complexity of observables and rxjs
RxJs seems complicated at the start but once you grok it you will never reach for a promise again. RxJs really is the best UI technology to come out in years, you just need to start thinking reactively.
Haven't gone near a promise or async awaits since I learned RxJs. RxJs is the best frontend technology in years.
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!
Thank you C# for async/await
The way of your explanation is really good and I understand the concepts well but the meme/joke videos are too long and distracting... Great video nonetheless.
I remember reading about AJAX on a newspaper. I'm not that old, but... Newspaper?!
I hate to be the one to break this to you but I think we're "old".
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.
I remember writing a Django application were a like button triggered a page refresh 😆
Simpler times! 😅