We have come to appreciate the performance and readability of the ol’ for loop. But, just how much should we be appreciating the performance? We already did a huge scientific study on different avatars of for. This is the time that we do another highly ineffective test for different types of loops so that we can prove nothing to no one.

Do not change those non-primitive function arguments without understanding the significant implications of your action. Programming languages have pass by reference and pass by value to pass arguments to a function. Javascript passes values for primitives, but references when you are trying to pass objects. Changing arguments within a function will change the arguments for ever.

Things are always not how they appear. Especially when it comes to multiplication of decimal numbers in Javascript. Consider - 1 const a = 1.1; Multiply the above number by 3. Compare with expected answer just to make sure you are not seeing a wrong answer. 1 2 3 4 5 6 const a = 1.

What if you want to allow changing props of an object, but do not want anyone to add new props? Well, that is what Object.seal is for. Objects in Javascript cannot be made immutable by using a const keyword. const works on primitives. It can also make sure you don’t reassign value to an object.

What if you want to play around with data, but also maintain metadata at the same time? In Javascript you don’t have to create other objects or work hard for that Nirvana that someone in the office was talking about. You just have to go ahead and store the darn metadata along with the object, and everyone is happy.

It is easy to take NaN for granted. But remember - the ‘not a number’ notation is the only powerful object that does not equal itself. First the essentials - you use NaN whenever you do not have variable values in control but want to do a numerical operation on it.

You can make mere variables and even an object immutable. But, how about a humble object prop? Making object props constant and immutable has practical usage. For e.g. consider this totally practical program to print out fruits and whether they are poisonous. 1 2 3 4 5 6 7 8 const eatable = { poisonous: false, printFruit: function(fruit) { return "name: " + fruit + " | poison: " + this.

You have used null. You have used undefined. But, have you ever thought about what they mean to the world and to Javascript? The fact is quite simple - we can’t do a null equality check. 1 2 3 4 console.log(1 == null); // false console.log(0 == null); // false console.

You can use bind to bind variables of a function, and execute the said function later to get the desired result. You have seen how how closures can be used in Javascript and a bit about currying functions. Here’s one more way of doing that. We can bind available variables for a function and execute function at a later time.

You can easily chain methods along with variables to find a highly readable, and totally sensible scope chain. We have seen how closures can be used in Javascript before. Let us see some more practical usage scenarios. Consider the below closure - 1 2 3 4 5 6 7 8 9 function getProduct(x) { return function(y) { return y * x; }; } const twice = getProduct(2); console.

Functions are objects in Javascript. So, we could use functions as objects within other functions. So, the below is valid - 1 2 3 4 5 6 7 8 9 10 11 12 function getProductPlus(x, y) { function factoredResult() { const factor = 2; //console.log("factored : ", x * y * factor); return x * y * factor; } return factoredResult; } let prod = getProductPlus(3, 5); console.

We have come to love and respect the fact that (almost) everything is an object in Javascript and we can use all kinds of variables without giving a damn about their types. But, we also can understand that Javascript is trying to work its magic when we throw all caution to the wind.

An object’s key can be anything - even a reserved keyword. And, this may cause unexpected problems in some script engines. Consider - 1 2 3 4 5 const operations = { add: "add something", delete: "remove something", prototype: "do something" }; operations is valid. And, you can go ahead and use the props in any way you wish.