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 🙏
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".
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 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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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!
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! :)
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 UA-cam, making your content more broadly accessible to the wider community! 👍
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.
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.
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
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.
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.
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 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
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.
Coming from a Haskell Background, this does remind me of Monads. The promise notation with .then() does work pretty much exactly, like the bind (>>=) operator works, and the async/await notation does seem like the JS version of the do-Notiation. Neet stuff.
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
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!
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".
Wow that buzzer/phone example was a stellar analogy for promise/callback
Thank you! Glad it was helpful.
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 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.
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'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
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!
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!
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.
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!
you always deliver awesome content
Thank you!
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.
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.
These are some high quality videos, happy the algorithm recommended this channel
Thank you!
JS Dev: Call me back when you get the chance
Date: No promises
😩😩😩
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 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 ❤️
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!
why is more important to me when learning new things and thanks for this.
Agree!
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!
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.
this is the best channel I've came across , thank you god 💘
Thanks for watching!
This is the most incredibly entertaining programming video I've ever seen
Glad you enjoyed it!
That's the best video on promises I have seen so far
Thank you!
The simplicity and depth of these tutorials are second to none.
Congratulations on the channel!
This is a phenomenal "Tutorial" history lesson!
So glad you enjoyed it!
🟡Wonderful hindsight and clear vision of technological advances.
Thank you!
For a guy who learned JS only from Async / Await - this is fucking amazing!
Thank you!
Great video! Always great to learn how one tool came to existence and what is the reason behind its existence.
Thank you!
100 for creativity , and 100 for content , thank you
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!
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!
i already used this in my capstone project and because of that i graduated BSIT college
now im continue to learn
This is the best explanation of asynchronous code I've ever seen!
Fireship style loving it!
Jeff is the 🐐
The restaurant analogy is helpful for understanding inversion of control. Thanks.
Glad it helped!
This is a brilliant video, uidotdev. Great job mate.
Thank you! Means a lot.
Oi, where was this 3 years ago when I needed it 😭
Thanks for watching!
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!
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'm so glad I found this channel!
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 UA-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?
I have never thought of Promises as eliminating inversion of control, pretty cool detail!
This was a damn good visual and conceptual analogy of Promises. Hats off to you sir.
Thank you!
This is awesome! Defo saving this for later.
Thank you!
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.
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!
Amazing video man! I can't believe I've been missing such great content. Thank you 🙏🏾🙏🏾
So glad you enjoyed it!
another banger from uidotdev
❤️
This is actually interesting not just for js but super well made,
Thanks. So good that I’m watching again to absorb
Thank you!
This is a gem.
Thank you!
Extremely clear explanations, subscribed !
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!
I'm a backend dev only learning about these amazing and powerful tools. It's pretty great
Glad you enjoyed it!
Simply remarkable! 😍
Thanks for watching!
Simply amazing!
Thank you!
Loving this series!
Thanks for watching!
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! :)
this is the best explanation out there 💯👌
Thank you!
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.
Promise.all() is still very useful and can be more convenient and robust than async-await
Man those examples are amazing.... very clear...
Thanks for watching!
Such a phenomenal channel! Keep up the great work...
❤️
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!
You deserve my subscription for this!!
Welcome!
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. ;)
Fantastic work
Thank you!
love the content
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!
👨💻👌 awesome video bro
Thank you!
Great vid! So smooth.
Thanks for watching!
Great video. Super easy to follow and very informative while also being engaging.
Thank you!
keeping making this kind of videos and also try to make another kind of videos too. So that I dont get bored.
I like these types of videos! More please! Subbed! Adblock disabled! 😁
Thank you!
Awesome video, thanks!
You're welcome!
Excellent explanation!
Thanks for watching!
Amazing!
❤️
0:08 Remember, everyone was a beginner once ☺
Amazing content, informative as well as entertaining. Your analogies are on point.
Much appreciated!
Damn man, you are amazing!
Thank you!
Great vídeo! Saved as part of my theory material. Subscribed
The explanation is beautiful, you've earned a new sub 👍
Welcome!
I got a wix ad right on the timing of "in 1999, everything changed"
😅
Keep it up! 😃
Thanks for watching!
@@uidotdev Pleasure!
Very well executed video! Keep up the good work. I just subscribed!
Thank you!
amazing content
Thank you!
amazing
Thank you!
I really like using
await new Promise(requestAnimationFrame);
It works wonders.
Keep posting more videos 😀
Working on it!
4:33 thats a good one :D
Thanks for watching!
Nice Introduction !
Thank you!
Thank you C# for async/await
Amazing content!
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.
Coming from a Haskell Background, this does remind me of Monads. The promise notation with .then() does work pretty much exactly, like the bind (>>=) operator works, and the async/await notation does seem like the JS version of the do-Notiation. Neet stuff.
All roads lead to monads.
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 🙈
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.