Probably not exactly three times slower because of engine optimizations, but you are correct, it is slower. That is one of the trade-offs that you as a developer should make, most of the times the improved readability is worth the performance decrease. If the reduce/map/filter structure is fast enough, great! If not, then it is time to optimize, otherwise it would be premature optimization.
Another thing to keep in mind at ~10:15 is that you're now doing 3 loops compared to one loop. At some point you have to wonder whether you want to give up runtime for readability, because the for loop is definitely going to be faster. It doesn't matter when you have one record, but if you have an array of multiple hundreds of thousands of records if you're running a batch or an import of something, it is going to make a difference if you reduce, filter, and map, or just do one for loop. Technically you could also just do it in one reduce function.
9:23 It should be a disclaimer that running the for-loop on orders once (in the code he advises against) is faster than iterating orders 3 times using orders.reduce, orders.map, and orders.filter. If orders is a huge array this could significantly impact performance, and then the for-loop would actually be an optimisation.
Timo M Yes, it should show chaining too, but even then it will be potentially a lot less performant than the simple single for-loop. Unless you are using Lazy.js or similar, of course.
Excellent video! I've been a JS developer for 20 years, and so I learned a ton from this. :) As an old-timer, I do have one comment on some of the efficiencies here: I prefer code clarity over code brevity. Shorter code is not necessarily easier to understand, especially for someone who is not yet a JS expert. So some of the tricks you showed I will absolutely be using, but others I won't just because - to me - they aren't as clear as what they are replacing. :)
@@botondhetyey159 You can also use console.error or console.warn. They add a little bit of color and make the console messages a lot clearer and you don't have to spend time on styling the console log
Most "pro" tip videos are pretty obvious syntax sugar in ES6; But I actually learned some cool stuff from this one! I can use console.table to print formatted arrays?? "Woah!" I can add inline styling to console.logs?? "Whaaattt!" I can use template literals to automagically destructure function parameters??? "Mind BLOWN!!" Great video!
For spread syntax keep in mind that it only shallowly creates a new object. If you have deeply nested variables those are copied by reference, so to keep immutability with a deep object you can do, var x = JSON.parse(JSON.stringify(some_obj)); Not sure of the time cost, but it’s an easy way to maintain immutability.
I watched your video on Async Await (in the future from this video's perspective) and I whole heartedly agree, even as one just starting to learn Javascript. For a month I was getting tired of all of the thens, THEN I found your Async Await video and boy oh boy, the game changed. I'm happy to have learned it from you early on rather than building lots of habits against it. Thank you for helping me get started on a good foot, and I love your teaching methods. Straightforward and zero filler.
Very nice video! But I find the Object.assign bit misleading. So I decided to comment here to clarify. In the video, he said instead of mutating an object, we might want to create a whole new object. Then he talked about Object.asign and said that object spread is just a syntactic sugar. This might mislead you to think that Object.assign will create a new object. But in fact, it doesn't. It mutates the first object in the arguments. And the object spread is only a syntactic sugar for Object.assign({}, ...), not for the whole Object.assign function. I hope this will clear things up. At last, thanks again to the creator for this informative, concise and easy-to-follow video!
Creating a copy of an object, which then can have alternative values. Is JSON parse the stringify-ed original object stored as new variable, achieves it?
I feel like i finally understand how to write JS for almost any type of project, but this video helped me realize I got a lot of work to do in terms of writing more efficient and clean code.
Please be very careful when condensing traditional loops to functions like map and filter... You can wind up running your loop several extra times, or in many cases dozens of extra times - per function call. It's often the case that a map or filter operation will be used by someone and re-run per element thousands of times on a single page load or interaction, and they'll even let it run on the UI thread... Concise code is good, and I like a lot of your recommendations but please exercise caution with convenience/style in the loop category. I see probably 3-4 times a month places in our prod code base that can be improved in execution time by orders of magnitude. We're talking seconds of wait time in production code used by tens of thousands of people daily. It's probably my number one pet peeve, wasting millions of cycles on fancy one liners. That's just my one crticism; it's not "💩" code to use manually indexed loops. It's usually the best solution.
I was wondering the same thing, it adds a lot of unnecessary looping especially if it's a big array just for syntactic sugar. If using a single function it makes a lot of sense but not if we are using map, filter and reduce all at the same time.
You're right, they are convenience methods because you often only need to solve one problem when looping, should have made the performance part a little more clear.
Let me be clear though: your videos are great, and I (along with others) appreciate the tremendous work put into them. So thank you! But we wouldn't be programmers without a little peer review ;D
Bruh you're kidding me with this console stuff. I showed this to my front end dev friends and _none of them had heard of it_ - you're a legend. Seriously this channel is next level stuff.
Good video. It's worth noting, by awaiting each function call like that, you are running all three functions synchronously. You can run them all in parallel by using Promise.all(), so the result would look like: const [first, second, third] = await Promise.all([random(), random(), random()])
Trying to watch this at night in bed in the complete darkness before I go to sleep, and the switching between dark & light screens made me for sure turn this into a tomorrow endeavor.
the console tips are awesome, I just want to say the more you know the better, but dont always use everything you know. Sometimes you might want to keep things more verbose but more understandable, but this is always something to mind about each case! Love the video btw
Really good video, thanks for making it! A bit of my own commentary. Personally I'd highlight `push` on arrays morphs the original array whilst the spread syntax creates a new array, therefore the spread syntax can be significantly slower. I think use cases exist for both. Object assign will morph the first argument, which I don't think is made super clear. Although array methods like filter, reduce and map are syntaxally really clean, I have found them to be significantly slower than for loops when working with large arrays. Again I think use cases exist for both. Besides that really awesome vid. Thanks for sharing!
Hey! Just want to say this is an awesome video! I know most of the things in this video but its great for a refresher or to send to other devs. Love your presentation and you make it really quick and informative. Kudos!
10:16 This type of stuff is nice on front-ends and/or for non-hot parts of code, but it should be known that on the backend it's not recommended if it regards the main workload of your code. In practically every multi-paradigm language loops result in much better performance than functional programming styles (even though FP is awesome). A function call and new variable initialization is a very small performance overhead, but it adds up much quicker than you would think with code like this.
Investment in stocks is a great way to invest your money. The team is constantly checking the market for changes and make sure that you are always informed about the best time to invest. As a result, I have made more money than ever before, and I don't have to manage my portfolio on my own! Invest in stocks, it's worth it!
*ROCHELLE DUNGCA-SCHREIBER* is my portfolio-coach, I found her on Bloomberg where she was featured, I looked up her name on the internet. Fortunately I came across her site and reached out to her, you can verify her yourself.
Dude you're an awesome instructor! Def subscribing. This video is probably gonna save my life, working an intership as the only other programmer besides my boss and not knowing much about JS Promises. lol
For large JS apps: - The structure of your code is way more important when it comes to writing 'good' JavaScript. - The mentioned features are not necessarily 'best practices'. You don't need async/await if you are working with observables.. - Styling the console output with css sounds like a terrible idea to me because debugging code should be temporary, my little picasso ;). I recommend debugging with the console like this: console.log('2 save item', item); This way, you can locate your debugging code easily and provide some meaning instead of just throwing out variables. Also you can add a number to check if your code runs in the right order (async code..).
Good points, thanks! I agree 100% with your first one. I think you meant Promises (not Observables) on the second point, which I encounter in every project and async/await truly boosts productivity and readability.
@@Fireship Thanks for the reply, I like your channel a lot! I did mean observables. In all our reactive applications we are using 0 promises and 0 async/awaits. It's just one paradigm of handling async code of many (imo inferior to observables). I agree with you that async/await is way better than promises which in return are way better than callbacks..
Point 2 isn't really a point, If you're working with observables you aren't working with promises and therefore async/await is not an option. If you're working with promises async/await is definitely best practice in 2018.
Awesome video with nice flow and presentation. But two small reminders 1) loops sometimes are faster if you can do stuff in one loop rather than two one liners. 2) If you use await improperly you pause the async function. So you might lose parallel execution chances. You should've put these a side note or warnings for new students :P. otherwise awesome video.
Could you give an example of 2? I never knew you could pause the async function improperly. In fact, I thought if you don't use await on an async function and you used the result, it would be undefined.
@@DanishAnton Better late than never, for future reference: In the example he showed (11:43) the three executions are independent of one another, meaning the 3rd async call, for example, does not rely on the results on the 1st or 2nd asyns calls. Using 'await' as he showed there is essentially a sequential execution, we first await the first call, then we initiate the second call and await it, then the 3rd cal... etc. But if the calls are independent they can (and should) be executed in parallel for better performances, this can be achieved by first initiating all calls and then awaiting all 3 promises, or better yet, by using Promise.all()
@@cinilaknedalm this. Making stylish Console log ain't really this useful, you use your ECP for debugging. And the async/await is "must-do" thing nowadays, unless you're not trying to make some legacy stuff while working with API.
Amazing lesson! Thanks! I'm shocked about console posibilities. I've realized I've always debugged in a wrong way
6 років тому+6
Array methods like reduce, map and filter perform much slower than classic for loops. So keep that in mind when you have to process large arrays. For small arrays it doesn't make much difference and the code is prettier, but a classic for loop can be over 10 times quicker.
I prefer readable code over discussable performance gain with preemptive optimizations. This was a case a few years ago but javascript engines of recent browsers are performing well with these methods. Future improvements are on the horizon as well. I believe one time for loop will be slower than the map, reduce or filter.
When talking about array concatenation you mentioned that `[].push` was the old way of doing it, but there is also [].concat() which is what babel does under the hood when using Array Destructuring.
I didn't know that template literal function magic... I saw that been used in styled components, but didn't realized you can just use it that way. Great tips!
Seriously ! One hell of a way of coding😎😎. Before this video i never knew that you can use css in console log(). Seriously thank you for that. Could you please do a video on cron jobs using firebase real-time or firestore database. async and await are the awesome things in the new JavaScript world. Seriously i wanna become pro member in your site. In any near future I ll become one. You're the most stylish and sexiest code developer I have ever seen. keeping doing this forever. There is a lot to learn from you.
Using a single for loop is better in terms of performance, since using separate ‘reduce’ ‘map’ and ‘filter’ will internally cause the object to be iterated thrice. The old for loop still exists for a reason and should not be discarded without considering the use case.
What are you talking about? Everything is this video IS far more readable (although in some cases sacrificing a bit of performance). These are modern JavaScript features, use them.
I agree. Some of these tips are really great, but it seems like some people believe better code == shorter, denser code, forgetting that humans have to read code too.
If your reaction to modern JavaScript features aiming to reduce errors like array index overflows and to simplify promises is "far more obscure", I wish you good luck lasting in this industry. Fun fact: people inheriting code I've written have actually commented that they now prefer using array methods over traditional for loops, go figure heh
Man I'd love to see one of your code examples... :D Simplifying things by absracting away unnecessary details, and telling the engine WHAT you want to do rather than HOW you want to do things makes your code way more readable, and sometimes more performant as well, because V8 can do crazy optimizations when you let it.
It might have to be 2028 for safari IE and edge to catch up, or for people to stop using them (preferably) so it's probably just javascript developer optimism to say its already 2019 xD
10:00 for anyone saying that this is bad for performance, modern engines are likely to merge the 3 loops into 1. *However,* in most cases this optimization isn't done, because if any of the arrow functions has the capability of throwing an error, the engine must keep track of where and when the exception was thrown. For that and other reasons I forgot, browsers are unlikely (but can) to optimize that O(3n) loop. However, (again) there's 2 other performance penalties, both have to do with property access: 1. All those array methods belong to `Array.prototype`, this means that the engine will do *3 sequential traversals* of the prototype chain. But engines already have a cache for built-in properties, and the Array prototype chain is small enough that can be considered O(3) (all method calls combined). 2. *Built-in objects can be modified at runtime!* Even if no code modifies the methods, the dev console can be used for that purpose, so the engine has to play safe and call the global methods instead of inlining them. In comparison to an indexed `for loop`. There's no property access, no accessing properties of global objects that can be modified, no prototype chain traversal, easy inlining and unrolling, no cache misses, and no dependency on the Array iterator (which can also be modified at runtime). All of these benefits happen because `for` loops are "raw syntax". However, funnily enough, `for of` loops rely on iterators of iterable objects, which means their behavior can also be modified at runtime without `eval`! even though these loops _seem to be_ pure syntax (the same happens with spread syntax "..."). I learned all of this while coding a library that tries to protect against EVERY external modification, for performance and security reasons. *JS is a hell for library developers LMAO*
I have never seen a video tutorial like this!!! Big thumbs up to fireship. Not what you are teaching but the way you are teaching is a 5 star.. very efficient code display for samples. unlike other tutorials, they tend to waste time typing the codes.
Everything old is new again... Very nice old school (very old school) debugging techniques in this video. Console debugging is obviously what one has to do when one cannot use a real Debugger but it is also ancient which means very old and not at-all modern or new. Kudos.
Readability is subjective though. There was a point in your career when you were first learning and most programs seemed quite cryptic. Eventually, you get used to reading code and you feel familiar with what you're used to reading day-to-day. I think when languages introduce new syntax to make our lives easier there's always a bit of resistance at first because people have to get used to seeing it. I remember when arrow functions were hard for me to read, and spread, and destructuring etc. Now I prefer to read code that makes use of those syntactic niceties. It's also pretty hard to argue that async/await is causing readability to plummet.
So is the beauty of a woman; subjective. Different per culture as well. And yet ... I think we all can agree that in general Margot Robbie is a hell of a lot more attractive than Rosie O’Donnell. Yes you are right, you can get used to syntax that is 'more efficient'; but readability implies code you don't *have* to go through a period to get used to syntax, to be able to understand what it does. It implies even if you don't know much about the code, you can still sort of understand what the code does. And a for() loop is much more common across languages and easier to understand than a map() function. It's like replacing a common word like "You" in a Harry Potter book with "1" and "Me" in with "2" ... confuses the shit when you read it, until, yes, you get used to the syntax .. and hey you've saved some ink and space!
"readability implies code you don't have to go through a period to get used to syntax" I don't really agree. Team standards evolve over time. There's always going to be something new to get used to. Readability in my opinion (and it's just my opinion, there's no science to this), is when you get understand what code is doing without having to think much about it. "getting used to syntax" is just an awkward period we all go through any time we're learning something new. Like a new language for example. Having methods on arrays/collections/lists or whatever data type is used in your language of choice is not new either. What language doesn't have `map` or the equivalent as part of its standard library or at least as part of a commonly included library? PHP, C#, JavaScript, and Python are 4 big ones that I know for sure have this. Pretty sure Java has supported lambdas for years now too hasn't it? Obviously, all of the big FP languages use this. I doubt the for loop is much more common than you think especially if we're talking about the most common languages that people actually use. For loops are less complicated. When comparing a simple iteration, sure, it's less verbose to just use a for loop. After that loops are way more convoluted and harder to parse. There's far too much cognitive overhead and state to hold in your head versus a map or a reduce which has no state and reads left to right like English. You don't have to jump up and down, or in and out to understand a chain of multiple maps and reducer functions. I think where these collection methods really shine is in situations where you would traditionally write nested loops. Learning how to map, reduce, pluck, flatten, filter, etc well pretty much means when you're doing a lot of work on a collection you'll never have to nest more than one indentation ever again. The less indentation and temporary state inside of a function the easier it is to read in my opinion. Imagine working with streams using loops - yuck.
I did most of this within FreeCodeCamp without knowing what it was for. This video proves to me when things are explained for their purpose, the mind absorbs them much easier. Your simple examples on reduce/map/filter, for example, were much easier to understand that the exercises where I didn't actually understand what the processes were for.
Рік тому
Man... I am learning JS on a academy. Every instance of a bad code in this video is the way they learn us to use. So I see the source of my frustration and confusion. Thanks! Now i need a lot of head rewiring to implement this.
@@Soremwar Oh boy, I have come a long way since this comment. At the time I was some kind of anti-library javascript programmer. Pretty cringe now that I think about it.
But constants are basically variables which cannnot be reassigned tho. Sure they have a different name though so its better to call them a const or constant
The await is over! The async/await video I promised is here ua-cam.com/video/vn3tm0quoqE/v-deo.html
Hi! Awesome video!, Learned a lot. I just wanted to know, which code editor are you using?
Love this video, it helped me fix up some of my old code.
holy crap this is useful for modding the new RPG Maker Engine since it's in JS.
Also interested about code editor...
VS Code ua-cam.com/video/u21W_tfPVrY/v-deo.html
00:48 how to use console.log
02:39 Object Destructuring
04:00 Template Literals
06:09 Spread Syntax
08:20 Loops
10:21 Async/Await
Thank you for this :)
@@Fireship I have a question: using reduce(), map() and filter() isn't 3 time slower than using a for loop? Especially with larger array/objects
YT needs a bot for every instructions video to do this.
Probably not exactly three times slower because of engine optimizations, but you are correct, it is slower.
That is one of the trade-offs that you as a developer should make, most of the times the improved readability is worth the performance decrease.
If the reduce/map/filter structure is fast enough, great! If not, then it is time to optimize, otherwise it would be premature optimization.
Code not this that
At first I was like "I can't think of anything this video could teach me".
After two minutes "I don't even know how console logging works..."
Print()
big same
LITERALLY
It's videos like this that remind me to never get comfortable with how I code, and to look at the specs for even the most simplest of code.
This comment is how we all reacted apparently.
console.table() --- mind blown
Super mindblown. Spent hours to convert JSON to csv table and turns out there is a way to instantly do that.
Read this and it will be much more difficult for the console to surprise you developers.google.com/web/tools/chrome-devtools/console/api
😲😲
===*
yeah really don't know whether this ever exists......
00:51 - Debugging with console.log
02:39 - Destructuring
03:59 - Template literals
06:07 - Spread syntax
08:19 - Loops
10:18 - async/await
Give this human a medal
If this were to be added to the video description, then UA-cam would automatically display this structure in the video progress bar.
No you need to add
00 - Start
aswell
Not the hero we deserve, but the hero we need right now
Add a 00:00 to the top of the list. Add the name as Intro
A coffe for the great content of the channel
Code not this that
I came here only to say this.
Don't dead open inside
I clicked on this video just to see if anyone made this comment.
Good man.
var _that = this;
Another thing to keep in mind at ~10:15 is that you're now doing 3 loops compared to one loop. At some point you have to wonder whether you want to give up runtime for readability, because the for loop is definitely going to be faster. It doesn't matter when you have one record, but if you have an array of multiple hundreds of thousands of records if you're running a batch or an import of something, it is going to make a difference if you reduce, filter, and map, or just do one for loop. Technically you could also just do it in one reduce function.
Fireship : So we're going to parse the arguments in it....
Me : Looses focus for a bit
Fireship : So yeah that's how you make Minecraft with JS
fireship*
R/woooosh
@Phương Nguyễn r/wooosh
xD i remember that.
Phương Nguyễn ua-cam.com/video/MAlSjtxy5ak/v-deo.html
It's a whole new level of console.log!
Show ua-cam.com/video/RQ5GVl8l3Zg/v-deo.html
Undefines
Yes
Mind-blowing
9:23 It should be a disclaimer that running the for-loop on orders once (in the code he advises against) is faster than iterating orders 3 times using orders.reduce, orders.map, and orders.filter. If orders is a huge array this could significantly impact performance, and then the for-loop would actually be an optimisation.
The advanced way should be a composition.
Timo M Yes, it should show chaining too, but even then it will be potentially a lot less performant than the simple single for-loop. Unless you are using Lazy.js or similar, of course.
How about .forEach?
John Dave Omandam forEach is same as regular for-loop, since forEach is basically just syntactic sugar for convenience.
@@magne6049 forEach creates overhead because of the new scope in the call stack, though.
A lot of valuable information in here, thanks so much. Not too basic, but also not confusingly high-level. The console table, "Oh that's sexy"
Wow, I had no idea about:
- console.table
- console.log({propertyName})
- CSS style in console.log
Thanks for the tips!
for me, 1st and 3rd
@@byronchamorro8826 thanks byron
You got to learn a lot.. 😂
Console.table actually seems useful
Excellent video! I've been a JS developer for 20 years, and so I learned a ton from this. :) As an old-timer, I do have one comment on some of the efficiencies here: I prefer code clarity over code brevity. Shorter code is not necessarily easier to understand, especially for someone who is not yet a JS expert. So some of the tricks you showed I will absolutely be using, but others I won't just because - to me - they aren't as clear as what they are replacing. :)
This is depressing and motivating at the same time
This is more a guide on how to use the latest JS features than a good pratices tutorial.
@@njpromethium xD
@@njpromethium you say that but I totally would lol
@@njpromethium It's not like that extra 5 seconds is not worth the big glowing red error message, so I actually notice it
@@botondhetyey159 You can also use console.error or console.warn. They add a little bit of color and make the console messages a lot clearer and you don't have to spend time on styling the console log
@@bill0x2a I watched and actually spend a good 10 minutes making a little message for my team
Most "pro" tip videos are pretty obvious syntax sugar in ES6; But I actually learned some cool stuff from this one!
I can use console.table to print formatted arrays?? "Woah!"
I can add inline styling to console.logs?? "Whaaattt!"
I can use template literals to automagically destructure function parameters??? "Mind BLOWN!!"
Great video!
I think it's nice even if it's just syntax sugar, because I notice that there are many changes in languages that people simply don't know of.
I've been learning JS for roughly a year now and this video seriously blew my mind, wish that I'd seen this sooner.
same reaction 🙃🙃
Ugh
@@loobakaer2 saw this early on in learning and tbh I don't understand it fully LMAOO
Shit, I just realized I don't know nothing about JS.
Thanks I thought I was the only one
me too wew
Use ESLINT.
lol
That's a double negative, so that means you must know something about JS!
"I can do a whole video on console logging"
Please do!!
He did
@@gradientO He did a video about console logging. We want him to console log the video.
For spread syntax keep in mind that it only shallowly creates a new object. If you have deeply nested variables those are copied by reference, so to keep immutability with a deep object you can do, var x = JSON.parse(JSON.stringify(some_obj));
Not sure of the time cost, but it’s an easy way to maintain immutability.
I watched your video on Async Await (in the future from this video's perspective) and I whole heartedly agree, even as one just starting to learn Javascript. For a month I was getting tired of all of the thens, THEN I found your Async Await video and boy oh boy, the game changed. I'm happy to have learned it from you early on rather than building lots of habits against it. Thank you for helping me get started on a good foot, and I love your teaching methods. Straightforward and zero filler.
Very nice video! But I find the Object.assign bit misleading. So I decided to comment here to clarify. In the video, he said instead of mutating an object, we might want to create a whole new object. Then he talked about Object.asign and said that object spread is just a syntactic sugar. This might mislead you to think that Object.assign will create a new object. But in fact, it doesn't. It mutates the first object in the arguments. And the object spread is only a syntactic sugar for Object.assign({}, ...), not for the whole Object.assign function. I hope this will clear things up. At last, thanks again to the creator for this informative, concise and easy-to-follow video!
Well explained, thank you for this 👍
Creating a copy of an object, which then can have alternative values. Is JSON parse the stringify-ed original object stored as new variable, achieves it?
I feel like i finally understand how to write JS for almost any type of project, but this video helped me realize I got a lot of work to do in terms of writing more efficient and clean code.
Please be very careful when condensing traditional loops to functions like map and filter... You can wind up running your loop several extra times, or in many cases dozens of extra times - per function call. It's often the case that a map or filter operation will be used by someone and re-run per element thousands of times on a single page load or interaction, and they'll even let it run on the UI thread... Concise code is good, and I like a lot of your recommendations but please exercise caution with convenience/style in the loop category. I see probably 3-4 times a month places in our prod code base that can be improved in execution time by orders of magnitude. We're talking seconds of wait time in production code used by tens of thousands of people daily. It's probably my number one pet peeve, wasting millions of cycles on fancy one liners. That's just my one crticism; it's not "💩" code to use manually indexed loops. It's usually the best solution.
I was wondering the same thing, it adds a lot of unnecessary looping especially if it's a big array just for syntactic sugar. If using a single function it makes a lot of sense but not if we are using map, filter and reduce all at the same time.
Yup my thoughts exactly. Traditional manual loops have been tested to be the most performant method in JS even if they're not one-liners.
You're right, they are convenience methods because you often only need to solve one problem when looping, should have made the performance part a little more clear.
I exactly had the same reaction and concern when I saw that part and checked the comments if anyone else mentioned it so I can thumbs up their comment
Let me be clear though: your videos are great, and I (along with others) appreciate the tremendous work put into them. So thank you! But we wouldn't be programmers without a little peer review ;D
Bruh you're kidding me with this console stuff. I showed this to my front end dev friends and _none of them had heard of it_ - you're a legend. Seriously this channel is next level stuff.
Unironically liked, commented, and subscribed. Amazing quality. Extremely informative while concise. Thank you!
I love how that while explaining the code, for each sentence you hit Control+Z
Ohhhhhh! I was wondering about that! That's so clever.
Yeah this guy is like genius
Good video. It's worth noting, by awaiting each function call like that, you are running all three functions synchronously. You can run them all in parallel by using Promise.all(), so the result would look like: const [first, second, third] = await Promise.all([random(), random(), random()])
I just discovered that there is - actually - a lot to learn about Javascript!
Many thanks
00:19 being rickrolled in a JavaScript tutorial is one of the last things I would imagine happening
Trying to watch this at night in bed in the complete darkness before I go to sleep, and the switching between dark & light screens made me for sure turn this into a tomorrow endeavor.
So much new modern stuff. I used to write a whole bunch of archaic code, since I come from the C/Java world.
Same bro.
1:43 Instead of using [ ], use { }. And instead of "index 0, 1, 2" it will display the actual names of the objects.
Oh my Godness! If this isn't BEAUTIFULLY written and efficient code, I wonder what is.
Best video I have seen in YEARS of learning programming.
You just delivered what's need to be delivered. Straight and Accurate. Bravo 🙏
First thing I want to say, the thumbnail for this video had some "DON'T DEAD OPEN INSIDE" vibes
ua-cam.com/video/g99yhG2mYec/v-deo.html here you go
the console tips are awesome, I just want to say the more you know the better, but dont always use everything you know. Sometimes you might want to keep things more verbose but more understandable, but this is always something to mind about each case! Love the video btw
Thumbnail: "Code This, NOT That"
My brain: "Code NOT This That"
@@HazemElsawy thumbnail
@@HazemElsawy thumbnail
@@HazemElsawy thumbnail
thumbnail
Don't dead open inside
Priceless man! The kind of things that you would never know by reading the doc, does js even have a doc, never seen it lol. thank you, thank you!
Best video/production/script/everything ever. Really cool, easy to understand but fast and straight to the point. Checking out the rest.
You, Sir...
you deserve a medal! I'm a junior FE Dev and you just blew my mind JS :D
Really good video, thanks for making it!
A bit of my own commentary.
Personally I'd highlight `push` on arrays morphs the original array whilst the spread syntax creates a new array, therefore the spread syntax can be significantly slower. I think use cases exist for both.
Object assign will morph the first argument, which I don't think is made super clear.
Although array methods like filter, reduce and map are syntaxally really clean, I have found them to be significantly slower than for loops when working with large arrays. Again I think use cases exist for both.
Besides that really awesome vid. Thanks for sharing!
Hey! Just want to say this is an awesome video! I know most of the things in this video but its great for a refresher or to send to other devs. Love your presentation and you make it really quick and informative. Kudos!
These videos are changing my life! Things I never thought of starting to learn coding.
I swear I'm gonna end up adding all your videos to my helpful web development playlist. These are so handy.
10:16
This type of stuff is nice on front-ends and/or for non-hot parts of code, but it should be known that on the backend it's not recommended if it regards the main workload of your code. In practically every multi-paradigm language loops result in much better performance than functional programming styles (even though FP is awesome). A function call and new variable initialization is a very small performance overhead, but it adds up much quicker than you would think with code like this.
Underrated comment.
awaiting the async/await video. HAHA
at least you can live your life while waiting ;)
line 1: await referenced before async keyword
hahaha you got me!
I promise you will get it
+wo997 promise unresolved
Investment in stocks is a great way to invest your money. The team is constantly checking the market for changes and make sure that you are always informed about the best time to invest. As a result, I have made more money than ever before, and I don't have to manage my portfolio on my own! Invest in stocks, it's worth it!
That's great! may I ask who's your portfolio manager?
*ROCHELLE DUNGCA-SCHREIBER* is my portfolio-coach, I found her on Bloomberg where she was featured, I looked up her name on the internet. Fortunately I came across her site and reached out to her, you can verify her yourself.
Those stuffs are just marvelous and the way you wrap it up in minutes is just mind-blowing . .
Dude you're an awesome instructor! Def subscribing. This video is probably gonna save my life, working an intership as the only other programmer besides my boss and not knowing much about JS Promises. lol
For large JS apps:
- The structure of your code is way more important when it comes to writing 'good' JavaScript.
- The mentioned features are not necessarily 'best practices'. You don't need async/await if you are working with observables..
- Styling the console output with css sounds like a terrible idea to me because debugging code should be temporary, my little picasso ;). I recommend debugging with the console like this:
console.log('2 save item', item);
This way, you can locate your debugging code easily and provide some meaning instead of just throwing out variables. Also you can add a number to check if your code runs in the right order (async code..).
Good points, thanks! I agree 100% with your first one. I think you meant Promises (not Observables) on the second point, which I encounter in every project and async/await truly boosts productivity and readability.
@@Fireship Thanks for the reply, I like your channel a lot! I did mean observables. In all our reactive applications we are using 0 promises and 0 async/awaits. It's just one paradigm of handling async code of many (imo inferior to observables). I agree with you that async/await is way better than promises which in return are way better than callbacks..
Point 2 isn't really a point, If you're working with observables you aren't working with promises and therefore async/await is not an option. If you're working with promises async/await is definitely best practice in 2018.
I would recommend debugging within your IDE if possible or using breakpoints, than using console.log's all over the place
when I'm writing tests I always use console.log() because they don't stop the tests and show data when you run the test.
When you playing checkers and someone breaks out the 3D chess board.
11:05 - oh my god, this is perfect! :D
6:15 I can respect someone who codes examples in Pokémon
Each JS project I write makes me realize how poorly I wrote previous JS projects.
This video made me realize they were all written poorly.
Thank you!
thank you, you are the best instructor on youtube
Amazing Video. How can guys dislike this if they are not interested in becoming a better programmer? LOL!
I learned a lot. Thanks!!!!
Awesome video with nice flow and presentation.
But two small reminders
1) loops sometimes are faster if you can do stuff in one loop rather than two one liners.
2) If you use await improperly you pause the async function. So you might lose parallel execution chances.
You should've put these a side note or warnings for new students :P. otherwise awesome video.
Could you give an example of 2? I never knew you could pause the async function improperly. In fact, I thought if you don't use await on an async function and you used the result, it would be undefined.
Danish Anton check out this techbrij.com/javascript-async-await-parallel-sequence you can see what I mean, accidentally doing this is probable
@@DanishAnton Better late than never, for future reference:
In the example he showed (11:43) the three executions are independent of one another, meaning the 3rd async call, for example, does not rely on the results on the 1st or 2nd asyns calls.
Using 'await' as he showed there is essentially a sequential execution, we first await the first call, then we initiate the second call and await it, then the 3rd cal... etc.
But if the calls are independent they can (and should) be executed in parallel for better performances, this can be achieved by first initiating all calls and then awaiting all 3 promises, or better yet, by using Promise.all()
@@amit-5463 Ahh, thanks
That spread syntax and template literal is something that I have used for months now after watching this video! Glad I subscribed a long time ago!
I turn into an explody-head emoji whenever I check out any of your videos! Thanks for BLESSING US with this channel!
2nd times watch this and still forgot almost everything, damn
lol me too
probably coz most of it unecessary stuff developers add to make themselves look hot, whilst making unreadable code.
@@cinilaknedalm maybe because he talk too fast lol
@@cinilaknedalm most of it is really usefull tho. I've been using it many times on my projects
@@cinilaknedalm this. Making stylish Console log ain't really this useful, you use your ECP for debugging. And the async/await is "must-do" thing nowadays, unless you're not trying to make some legacy stuff while working with API.
Amazing lesson! Thanks! I'm shocked about console posibilities. I've realized I've always debugged in a wrong way
Array methods like reduce, map and filter perform much slower than classic for loops. So keep that in mind when you have to process large arrays. For small arrays it doesn't make much difference and the code is prettier, but a classic for loop can be over 10 times quicker.
I prefer readable code over discussable performance gain with preemptive optimizations.
This was a case a few years ago but javascript engines of recent browsers are performing well with these methods. Future improvements are on the horizon as well. I believe one time for loop will be slower than the map, reduce or filter.
When talking about array concatenation you mentioned that `[].push` was the old way of doing it, but there is also [].concat() which is what babel does under the hood when using Array Destructuring.
I didn't know that template literal function magic... I saw that been used in styled components, but didn't realized you can just use it that way. Great tips!
i like how const {} betrayed the "with" keyword
Haha, .then() always reminded me of Dude where is my car. Cool tip about the console table, didn't even know you could do something like that
Glad to hear I'm not the only one, haha
Seriously ! One hell of a way of coding😎😎. Before this video i never knew that you can use css in console log(). Seriously thank you for that. Could you please do a video on cron jobs using firebase real-time or firestore database. async and await are the awesome things in the new JavaScript world. Seriously i wanna become pro member in your site. In any near future I ll become one. You're the most stylish and sexiest code developer I have ever seen. keeping doing this forever. There is a lot to learn from you.
Haha, thank you for the suggestions. I'll big plans to create better content and more of it :)
Go to Facebook and open the console. You'll see a CSS-styled warning message.
This is so amazing! I didn't know about how to send data to tables and even style it in the console. How cool!
This channel posts some of the best javascript tips and tricks.
Using a single for loop is better in terms of performance, since using separate ‘reduce’ ‘map’ and ‘filter’ will internally cause the object to be iterated thrice.
The old for loop still exists for a reason and should not be discarded without considering the use case.
It seems to me "more readable" here means "far more obscure".
Which the next guy reading your code will really love...
What are you talking about? Everything is this video IS far more readable (although in some cases sacrificing a bit of performance). These are modern JavaScript features, use them.
I agree. Some of these tips are really great, but it seems like some people believe better code == shorter, denser code, forgetting that humans have to read code too.
If your reaction to modern JavaScript features aiming to reduce errors like array index overflows and to simplify promises is "far more obscure", I wish you good luck lasting in this industry.
Fun fact: people inheriting code I've written have actually commented that they now prefer using array methods over traditional for loops, go figure heh
Man I'd love to see one of your code examples... :D Simplifying things by absracting away unnecessary details, and telling the engine WHAT you want to do rather than HOW you want to do things makes your code way more readable, and sometimes more performant as well, because V8 can do crazy optimizations when you let it.
Please make the await async video, please. Thanks!
Only bit of consumer Feedback I can give is slowing it down a bit. Especially when running through code. Just a bit. Content is amazing! Thanks!
I love the short comedic clips that you insert into these
Last time I was this early JavaScript was still called LiveScript.
Haha
♪ never gonna turn around and.... desert you ♫
Damn it has been a while since the last time I was rick-roll'd.
uh it's not 2019?
I'm living in the future :)
yeah its 2018
time travel is real?
This is futuristic video, so it doesn't matter
It might have to be 2028 for safari IE and edge to catch up, or for people to stop using them (preferably) so it's probably just javascript developer optimism to say its already 2019 xD
10:00 for anyone saying that this is bad for performance, modern engines are likely to merge the 3 loops into 1. *However,* in most cases this optimization isn't done, because if any of the arrow functions has the capability of throwing an error, the engine must keep track of where and when the exception was thrown. For that and other reasons I forgot, browsers are unlikely (but can) to optimize that O(3n) loop.
However, (again) there's 2 other performance penalties, both have to do with property access:
1. All those array methods belong to `Array.prototype`, this means that the engine will do *3 sequential traversals* of the prototype chain. But engines already have a cache for built-in properties, and the Array prototype chain is small enough that can be considered O(3) (all method calls combined).
2. *Built-in objects can be modified at runtime!* Even if no code modifies the methods, the dev console can be used for that purpose, so the engine has to play safe and call the global methods instead of inlining them.
In comparison to an indexed `for loop`. There's no property access, no accessing properties of global objects that can be modified, no prototype chain traversal, easy inlining and unrolling, no cache misses, and no dependency on the Array iterator (which can also be modified at runtime).
All of these benefits happen because `for` loops are "raw syntax". However, funnily enough, `for of` loops rely on iterators of iterable objects, which means their behavior can also be modified at runtime without `eval`! even though these loops _seem to be_ pure syntax (the same happens with spread syntax "...").
I learned all of this while coding a library that tries to protect against EVERY external modification, for performance and security reasons. *JS is a hell for library developers LMAO*
I have never seen a video tutorial like this!!! Big thumbs up to fireship. Not what you are teaching but the way you are teaching is a 5 star.. very efficient code display for samples. unlike other tutorials, they tend to waste time typing the codes.
I can't keep up with what is going on in this video...Anxiety Intensifies!!!
I feel like I'm being shown forbidden knowledge
5:44 My head explodes here.
i know your feel LOL
Same here. In a million years I never would have thought to try that.
I'm a year late, but
Everything old is new again... Very nice old school (very old school) debugging techniques in this video. Console debugging is obviously what one has to do when one cannot use a real Debugger but it is also ancient which means very old and not at-all modern or new. Kudos.
Thanks to this video, I've finally grasped the entire concept of async await. Great explanation! :)
what is you color theme, please?
vscode -> Store ->AtomTheme
"Code Not This That"
Apparently I've been console logging completely wrong this whole time!
Over five years. Yet, you sir have taught me way more in twelve minutes.
Wooow!!!
Those tips about console was really useful!!
Thank you! I'll never forgot this!😃
Yeah you reduced a lot of Code lines, but i also think that it did not really make it easier to read. It is actually just less. Most of the time...
I find this is a very common thing when using JS. People like to get cute, then the readability plummets.
Not just JS; this goes for all programming languages.
Readability is subjective though. There was a point in your career when you were first learning and most programs seemed quite cryptic. Eventually, you get used to reading code and you feel familiar with what you're used to reading day-to-day. I think when languages introduce new syntax to make our lives easier there's always a bit of resistance at first because people have to get used to seeing it. I remember when arrow functions were hard for me to read, and spread, and destructuring etc. Now I prefer to read code that makes use of those syntactic niceties. It's also pretty hard to argue that async/await is causing readability to plummet.
So is the beauty of a woman; subjective. Different per culture as well. And yet ... I think we all can agree that in general Margot Robbie is a hell of a lot more attractive than Rosie O’Donnell.
Yes you are right, you can get used to syntax that is 'more efficient'; but readability implies code you don't *have* to go through a period to get used to syntax, to be able to understand what it does. It implies even if you don't know much about the code, you can still sort of understand what the code does. And a for() loop is much more common across languages and easier to understand than a map() function.
It's like replacing a common word like "You" in a Harry Potter book with "1" and "Me" in with "2" ... confuses the shit when you read it, until, yes, you get used to the syntax .. and hey you've saved some ink and space!
"readability implies code you don't have to go through a period to get used to syntax" I don't really agree. Team standards evolve over time. There's always going to be something new to get used to. Readability in my opinion (and it's just my opinion, there's no science to this), is when you get understand what code is doing without having to think much about it. "getting used to syntax" is just an awkward period we all go through any time we're learning something new. Like a new language for example.
Having methods on arrays/collections/lists or whatever data type is used in your language of choice is not new either. What language doesn't have `map` or the equivalent as part of its standard library or at least as part of a commonly included library? PHP, C#, JavaScript, and Python are 4 big ones that I know for sure have this. Pretty sure Java has supported lambdas for years now too hasn't it? Obviously, all of the big FP languages use this. I doubt the for loop is much more common than you think especially if we're talking about the most common languages that people actually use.
For loops are less complicated. When comparing a simple iteration, sure, it's less verbose to just use a for loop. After that loops are way more convoluted and harder to parse. There's far too much cognitive overhead and state to hold in your head versus a map or a reduce which has no state and reads left to right like English. You don't have to jump up and down, or in and out to understand a chain of multiple maps and reducer functions.
I think where these collection methods really shine is in situations where you would traditionally write nested loops. Learning how to map, reduce, pluck, flatten, filter, etc well pretty much means when you're doing a lot of work on a collection you'll never have to nest more than one indentation ever again. The less indentation and temporary state inside of a function the easier it is to read in my opinion.
Imagine working with streams using loops - yuck.
Its not 2019 tho
Everything i knew about console.log was crap
ua-cam.com/video/L8CDt1J3DAw/v-deo.html
I did most of this within FreeCodeCamp without knowing what it was for. This video proves to me when things are explained for their purpose, the mind absorbs them much easier. Your simple examples on reduce/map/filter, for example, were much easier to understand that the exercises where I didn't actually understand what the processes were for.
Man... I am learning JS on a academy. Every instance of a bad code in this video is the way they learn us to use. So I see the source of my frustration and confusion. Thanks! Now i need a lot of head rewiring to implement this.
When you have to support IE11 :(
Babel and Deno got you covered
@@Soremwar Oh boy, I have come a long way since this comment. At the time I was some kind of anti-library javascript programmer. Pretty cringe now that I think about it.
@@azertycraftgaming Lol One of the best things in life is seeing personal growth in UA-cam comments
@@Soremwar haha
Whenever I see someone calling const a variable I get triggered (and it's all too common in JS world >_
But constants are basically variables which cannnot be reassigned tho. Sure they have a different name though so its better to call them a const or constant
Code This Not that: 😔
Code Not That This: 😎
Wow i never thought i could learn something new from this video. Thanks a lot.
This is honestly the best channel on UA-cam for JavaScript explainers - thank you for the great content! Makes it really easy to understand 🙂