Do you know these JS concepts?
HTML-код
- Опубликовано: 4 авг 2024
- Basic JavaScript concepts every web developer should know.
💬 Topics:
- Expressions and statements;
- var, let and const;
- this keyword, call, apply and bind;
- Temporal dead zone;
- Scope: block, function and global
- Objects and classes;
- Promises / async await;
- Functional programming concepts.
#javascript
Commenting for the algorithm 😁. A deep dive on JS Event Loop from you would be awesome 🥳
Thank you! Will work on it!
I like this type of videos! This will help people get the idea on what to focus when learning a new language!
Thanks!
+1
I'm glad it helps!
Nice one! Thanks :D
Keep up the great videos. And make more these types of videos
Thank you! Will do!
Thanks it's great for quick revision
Glad you liked it! Thank you!
thank you
Very good explanation of JS concepts. Thanks.
Glad it was helpful!
Actually, closure is specifically the capability of a inner function to access a variable of a outer function even after the outer function have finished running, not just accessing a outer function variable.
You got a subscriber ... ❤great content
Thank you!!
Yooo you are my new favorite JS channel
Thank you so much!
Found another gem.go strong
Thank you!
Is there a difference in performance between == and ===? Let's say I use typescript and am sure that == provides sufficient comparison, should I still use === just to be safe or will == save me some nanoseconds of execution time? A good example if this would be the snippet `if (typeof window == "undefined")` which I write way too often in Next apps.
This is actually a very good question.
1. These operators are so "small" that the performance difference (if any) is pretty tough to compare.
2. However, simple equality (==) will do type coercion if necessary, and this is an extra step which takes time. Therefore:
- 2 == 2 and 2 === 2 will both return true, and will perform the same.
- 2 === "2" will return false. 2 == "2" will return true, but the evaluation will take longer than the previous one, because the two variables need to be brought to the same type.
In conclusion, if you use Typescript (which ensures the same type), double and triple equal will perform the same. In a plain JavaScript environment, the double equal will take slightly more time to give you a true or a false, if the type coercion is applied.
These things are trivial for compilers to optimize away (JIT or otherwise). That said, the hypothetical nanoseconds you might save from a micro-optimization such as this pales in comparison to the literal seconds you might need to fetch and process the information regarding this distinction inside of your head every time you or someone else reads your code.
Other than that, there's a historical perspective as well. === exists simply because the original implementation of == was buggy, and it was too late to introduce breaking changes to the language by the time they realized how big of a misfeature this is. So, === is THE equality operator in JS, both philosophically and in practice.
Lastly, TS projects that are 100% provably correct are super rare. Due to the underlying nature of the Web and JS, your code almost always depends on some assumptions or 'promises' you made to the compiler. In other words, there's a tiny chance that using == when you really mean === could introduce bugs, even if you're using TS.
I think there is a syntax error at line 9 of the code for functional programming - missing “)” 10:55
You are right. Thank you!
Yeah, JS is a solid top 1 among the developers. Cool
So why would you use curring?
Currying actually isn't idiomatic in JS, despite what these youtube videos might have you believe. JS doesn't really have automatic currying. All these examples are just simulating the real thing manually, which more often than not takes more effort compared to just decomposing your program into smaller functions.
Let me explain the situation with an example.
Suppose you have a function add(a, b) which adds two numbers, and a map(list, func) which takes a list of numbers and a function, and applies the function over each of the numbers ultimately returning a new list with the outputs. The function being passed here clearly has to take a number and return a number.
Now suppose you have such a list [1, 2, 3, 4...]. Your task is to make a new list from this but add two to each of the numbers: [3, 4, 5, 6...]. How do you go on to solve this with what you already have? Well, in a language with automatic currying you could just write map(list, add(2)). The add() function is automatically curried here, so everything works perfectly.
In order to achieve the same in JS you would have to modify the function as shown in the video, and write a whole lot more code. But I'm not going to give you that example here, instead here's what you'd really do in idiomatic JS: you would just pass a lambda, giving us map(list, a => add(2, a)). This isn't too much work, and has the quality of being explicit instead of depending on invisible language features. You can have your cake, and eat it at the same time.
More js concepts !!
Thank you for the feedback! It’s on the list!
1:18 [1,2].pop() would actually produce 2. shift() would've produced 1. Might've made a typo over there my guy.
Damn.. 🤦♂️ You are right about that.
Thank you for pointing it out.
@@awesome-coding No biggie. You're "awesome". 😏
more please
Will do!
Yes, feed me more
your accent is kinda hard to understand but thank you anyways
Thank you for the feedback! Hopefully I'm slowly fixing the accent problem as well 😅