Hey everyone, welcome back and in this article, let’s just discuss an interesting topic in JavaScript which are my 5 favorites Do’s and Don’ts as a Developer even as a Senior Developer I should rather say because this is something a mistake we can all make. Let’s just go ahead and discuss my top 5 list.
Table of Contents
1. Strict Mode in JavaScript
So I am going to start with number one which I feel a lot of people still don’t make use of. That is making use of strict mode in JavaScript. Now as you can also see on MDN documentation, strict mode is really recommended. And it is actually enabling a completely different set of the way the JavaScript engine views your code. A lot of things that are marked as warnings are actually converted into errors if you are using strict mode in JavaScript. And enabling street mode is also not difficult.
How to enable Strict Mode in JavaScript?
All you have to do is in your JavaScript file use using “use strict” mode at top of your JavaScript file inside of double quotes or single quotes. The moment you do that, a browser engine, for example, V8, if it sees it, it’s going to trigger the strict version of JavaScript.
As you can already see on MDN docs, there are a bunch of advantages and a bunch of things that should get out of strict mode when you are using it properly.
2. Stick to Monomorphism
The second point that is super important again as a JavaScript developer and sometimes even for Senior JS Developer is that actually use JavaScript in a Monomorphic way. What does the system exactly mean? Because I know that a lot of people here would not have an idea about what a Monomorphic and Polymorphic thing is. So instead of going to go into the definition, I’m going to give you a simple example.
Let’s just say you have a JavaScript function named “add” and you expect two numbers x, y and you just return x + y. Now, what happens in JavaScript is that if you call this add function over and over again with just numbers if you just call this function something like add(1, 2) or add(5,7) like this. What will eventually happen is that if you keep on calling this with just numbers, JavaScript internally, V8 internally would optimize the machine code for this.
And the way V8 works isfor example, initially let’s say you are writing this code. What V8 would do in the machine language the machine code itself is, say that we have an argument x and then we need to call the function to get the result. But after optimizing it, V8 could actually see because you’re actually using numbers with this function I’m going to optimize this in a way where I don’t have to call this in JS way. I can just directly call it in the machine code which is you know x86 or whatever.
But what happens if you start calling it in a way like this, for example, add(2, a) then of course you know JavaScript that it will return you 2a as a string, but the moment you do this, the V8 engine internally de-optimizes this function. That means this function would now run much slower, in fact, 10-100 times slower in some cases compared to hits Monomorphic version.
So the Monomorphic version was the one where you were only passing in a single input, a single type of input and the Polymorphic version was the one where you know the JavaScript compiler has to de-optimize its optimization and then call the JS version again and again. So the flexibility which JavaScript gives you comes at a huge performance hit which the JavaScript engines try to fix by optimizing the code. But if you do weird stuff within the JS world like this, for example, you might be following a pattern which is like an array of objects where a first element is a number and the second element is a string. It’s a very well pattern. There’s nothing wrong with it, but it is possible that if you use this pattern then the JavaScript engine is not able to optimize your and it de-optimizes it. It’ll still run it obviously because JavaScript supports it, but it’ll not be as performant. You’ll have 10-100 times the performance penalty on such codes.
3. Strict Equality (===)
The third tip which I have for you is to actually use strict equality in JavaScript. Now there is absolutely no reason at all to use double equality in JavaScript, except for only a single reason, which I know is that if you want to compare a variable with both undefined and null together. Because when you use double equality then undefined and null actually just match in a single statement. So you don’t have to do value === undefined or value === null. So this is the only case which I know and again this also becomes sometimes confusing. So you should probably avoid this as well.
Other than that there is no reason to use (===) in JavaScript. It’ll save you tons of headaches, tons of type questions. So small tip but super important.
4. Don’t Pollute Protptypal Chains of Native Data Structure
The fourth tip for you would be, don’t pollute prototypal chains of native data structures. For example, string, number, object, etc. Because what happens is that, I’m not sure how many of you have heard about MooTools but MooTools is a slash system where it heavily added features to JavaScript by prototyping of existing data structures. String, numbers, objects in JavaScript. Now, the way these things were implemented because MooTools was very popular back in the day. When new standards of JavaScript came in, for example, Ecmascript, which released features like includes on a string and contains, and so on. So they were not able to release it properly because MooTools was a very widespread library. It patched a lot of functions in the prototypal chain itself which led to the fact that the committee decided that if we shift this as a new feature in the language it’ll break a lot of existing Web.
So similarly anytime you use a library or you do it yourself where you pollute the native prototypal chain of a data structure you actually contribute to the world where we might have restrictions on what features ship to these new prototype chains because thefundamental philosophy of Web is that we don’t try to break the Web. The sites which are working 20 years before should be working now in modern browsers and we cannot do that if we actually pollute the place where the new features have to be added. That is the prototype will change.
So don’t use libraries like MooTools or any other features which actually require you to directly add to (string.prototype.something). Because there are always better ways, better techniques to use. But don’t use these libraries and practices yourself because you’ll probably be contributing in a Web where the Web is rigid and cannot grow.
5. Modern Syntax In JavaScript
My 5th and final tip is – always try to use modern syntax over primitive one. The best example for this is async-await over promises, promises over callbacks. Because when you use modern syntax not only do you make your code read and feel much simpler but also help you in performance. We accept that modern features are more performant, better implemented, and much more secured in terms of bugs and stuff.
So Async Await is definitely an example of this. Promises is an example of this over Callbacks. The let and const variable declaration is an example of this. Use strict is also I would put it in modern syntax although it’s not modern syntax, it’s has been alive there for a while. Still, you should use all these modern practices.
Please don’t follow video tutorials that teach you older practices. JavaScript has matured a lot and it’s much easier to work with it you do just a few things right.
So this is it for the Top 5 JavaScirpt Do’s & Don’ts. If you are a JS developer I hope these were helpful!!