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.
@@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
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. :)
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.
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.
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?
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
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.
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 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.
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
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.
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.
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!
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.
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.
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
5 лет назад+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.
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 I did was put on a 'rainfall on tin roof' video to play in the background at just the right soft volume. Also a video of a fireplace. Then watched this video as if you were telling us stories beside the fireplace in a cottage at the base of a steep valley on a rainy night.
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.
"Javascript is a programming language." Well said, couldn't have put it better myself
9 месяцев назад
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.
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.
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!
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
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
At 10:09, by using reduce+map+filter you are increasing the complexity of the computation of x3: in the old (and ugly) flow of the for loop the data source is iterated once, in the other case 3. This is obviously in the world of theory... in practice I fully agree with your approach 😃
But pros don't need debuggers ;) A good advantage of using console.log() is that the debugging is portable, you don't need to have that specific IDE that has the debugging ability. Also debuggers are pretty slow, so if you are well versed with console.log(), you can pretty much get everything that an IDE would give you, but with more versatility. However, if you are doing very low level coding (C/C++) IDE debuggers can help a lot with stack traces and memory management.
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.
There's a lot of talk about performance issues with too much looping, which I can see are valid concerns, but I think readable code is severely underrated. There's the adage that you shouldn't need to leave comments in your code if you've written good code, but how many people have written bad code and then forgotten to comment about what it's supposed to be doing because they tried to nail the most optimal solution on the first try? If the code is "bad" insofar as it's using built-in looping methods such as map and filter that are causing performance issues, but it's easy to read because the coder used those methods, it's far easier to optimize on a case-by-case basis as it's discovered that those methods aren't the best solution. If you have twelve filter loops and only one of which is accessing too much data for that solution to be optimal. You can change one line of code to an indexed for loop and leave the others alone. But if you're experiencing issues with a giant for loop trying to do 12 things and the original coder left no notes, you'll spend a lot of time just trying to read it even before you discover which part is causing performance issues, let alone designing a solution to the problem. Rapid, readable, fixable code > perfectionistic, obfuscated code.
I thought that I was the only one: I watched this video twice thinking my brain got frozen the first time. Anyone that's a beginner shouldn't come near this video at all... never ever.
@@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.
The only time I don't use destructuring is when I would like to preserve the "pass by reference" nature of objects when passed as arguments in functions. const a = { value: 0 }; function updateA ({value}) { value++; } function updateB (object) {object.value++; } updateA(a); console.log(a.value); //will display 0 when you try to access a.value. updateB(a); console.log(a.value); //will display 1 when you try to access a.value; Very nifty especially if you want to have a "read-only" style of access to object members versus if you want to save extra lines of code just to make destructured native value object members reflect to itself.
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
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.
The await is over! The async/await video I promised is here ruclips.net/video/vn3tm0quoqE/видео.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 ruclips.net/video/u21W_tfPVrY/видео.html
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.
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
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 RUclips 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
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 ruclips.net/video/MAlSjtxy5ak/видео.html
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;
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"
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.
This is depressing and motivating at the same time
It's a whole new level of console.log!
Show ruclips.net/video/RQ5GVl8l3Zg/видео.html
Undefines
Yes
Mind-blowing
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!
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
"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.
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.
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
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. :)
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
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.
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.
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?
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
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.
1:43 Instead of using [ ], use { }. And instead of "index 0, 1, 2" it will display the actual names of the objects.
Thumbnail: "Code This, NOT That"
My brain: "Code NOT This That"
@@HazemElsawy thumbnail
@@HazemElsawy thumbnail
@@HazemElsawy thumbnail
thumbnail
Don't dead open inside
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
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.
00:19 being rickrolled in a JavaScript tutorial is one of the last things I would imagine happening
First thing I want to say, the thumbnail for this video had some "DON'T DEAD OPEN INSIDE" vibes
ruclips.net/video/g99yhG2mYec/видео.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
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.
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.
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.
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.
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!
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!
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.
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
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.
You, Sir...
you deserve a medal! I'm a junior FE Dev and you just blew my mind JS :D
Unironically liked, commented, and subscribed. Amazing quality. Extremely informative while concise. Thank you!
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!
11:05 - oh my god, this is perfect! :D
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
When you playing checkers and someone breaks out the 3D chess board.
I swear I'm gonna end up adding all your videos to my helpful web development playlist. These are so handy.
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.
6:15 I can respect someone who codes examples in Pokémon
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!
i like how const {} betrayed the "with" keyword
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.
Amazing Video. How can guys dislike this if they are not interested in becoming a better programmer? LOL!
I learned a lot. Thanks!!!!
What I did was put on a 'rainfall on tin roof' video to play in the background at just the right soft volume. Also a video of a fireplace. Then watched this video as if you were telling us stories beside the fireplace in a cottage at the base of a steep valley on a rainy night.
You just delivered what's need to be delivered. Straight and Accurate. Bravo 🙏
thank you, you are the best instructor on youtube
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.
♪ never gonna turn around and.... desert you ♫
Damn it has been a while since the last time I was rick-roll'd.
"Javascript is a programming language." Well said, couldn't have put it better myself
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.
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
Last time I was this early JavaScript was still called LiveScript.
Haha
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.
This channel posts some of the best javascript tips and tricks.
This is the kind of stuff that helps me not to fucking hate java script, but actually kinda start to like it
Please make the await async video, please. Thanks!
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
Apparently I've been console logging completely wrong this whole time!
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!
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
I can't keep up with what is going on in this video...Anxiety Intensifies!!!
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
"Code Not This That"
I love the short comedic clips that you insert into these
Best video/production/script/everything ever. Really cool, easy to understand but fast and straight to the point. Checking out the rest.
I feel like I'm being shown forbidden knowledge
Everything i knew about console.log was crap
ruclips.net/video/L8CDt1J3DAw/видео.html
what is you color theme, please?
vscode -> Store ->AtomTheme
Those stuffs are just marvelous and the way you wrap it up in minutes is just mind-blowing . .
At 10:09, by using reduce+map+filter you are increasing the complexity of the computation of x3: in the old (and ugly) flow of the for loop the data source is iterated once, in the other case 3. This is obviously in the world of theory... in practice I fully agree with your approach 😃
"Debugging like a pro"
>Use console.log()
Wtf ?
Using a proper debugger is way better and actually easier than it looks like
But pros don't need debuggers ;) A good advantage of using console.log() is that the debugging is portable, you don't need to have that specific IDE that has the debugging ability. Also debuggers are pretty slow, so if you are well versed with console.log(), you can pretty much get everything that an IDE would give you, but with more versatility.
However, if you are doing very low level coding (C/C++) IDE debuggers can help a lot with stack traces and memory management.
Can't debug jquery, for example
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
There's a lot of talk about performance issues with too much looping, which I can see are valid concerns, but I think readable code is severely underrated. There's the adage that you shouldn't need to leave comments in your code if you've written good code, but how many people have written bad code and then forgotten to comment about what it's supposed to be doing because they tried to nail the most optimal solution on the first try? If the code is "bad" insofar as it's using built-in looping methods such as map and filter that are causing performance issues, but it's easy to read because the coder used those methods, it's far easier to optimize on a case-by-case basis as it's discovered that those methods aren't the best solution. If you have twelve filter loops and only one of which is accessing too much data for that solution to be optimal. You can change one line of code to an indexed for loop and leave the others alone. But if you're experiencing issues with a giant for loop trying to do 12 things and the original coder left no notes, you'll spend a lot of time just trying to read it even before you discover which part is causing performance issues, let alone designing a solution to the problem. Rapid, readable, fixable code > perfectionistic, obfuscated code.
I thought that I was the only one: I watched this video twice thinking my brain got frozen the first time. Anyone that's a beginner shouldn't come near this video at all... never ever.
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 RUclips comments
@@Soremwar haha
Code This Not that: 😔
Code Not That This: 😎
to fast explaining, I can't catch up, and no output
The only time I don't use destructuring is when I would like to preserve the "pass by reference" nature of objects when passed as arguments in functions.
const a = {
value: 0
};
function updateA ({value}) { value++; }
function updateB (object) {object.value++; }
updateA(a);
console.log(a.value); //will display 0 when you try to access a.value.
updateB(a);
console.log(a.value); //will display 1 when you try to access a.value;
Very nifty especially if you want to have a "read-only" style of access to object members versus if you want to save extra lines of code just to make destructured native value object members reflect to itself.
9:29 Wow, you say I should loop my array 3 times instead of 1. You're genius
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
"How to write even slower JS"
In 99% of cases, readability and maintainability is greater than performance.
Performant code doesn't mean unreadable, and vise versa.
Could you please speak faster? I was getting bored waiting for you to finish ideas... ;)
Watch it at 2x
This is already fast
@@royhonders I was actually just poking fun at his speed cos he was way too fast.
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.
i've been working with JS for 7 months now and the only thing i didn't know about here was the console.table(). Still enjoyed this a lot.