JavaScript Prototypes — the part most people misunderstand Most JavaScript magic comes from one rule: Property access walks the prototype chain The lookup rule (exactly how JS works) When you do: obj.key JavaScript checks in this order: obj obj.__proto__ obj.__proto__.__proto__ …until null No copying. Only delegation. prototype vs __proto__ (interview classic) function Person(name) { this.name = name; } const p = new Person("Alex"); What’s actually true: p.__proto__ === Person.prototype prototype → property of constructor functions __proto__ → internal link on objects new connects them Why methods belong on prototype Person.prototype.sayHi = function () { return "Hi " + this.name; }; One function in memory Shared by all instances Faster & cleaner than redefining per object The dangerous part ⚠️ Person.prototype.age = 25; You didn’t update one object. You updated every object linked to that prototype. This is how global bugs are born. Mental model 🧠 Objects don’t inherit properties. They delegate lookups. Senior takeaway 🥇 If you understand prototypes: class becomes obvious this makes sense Method sharing is clear Many “weird JS bugs” disappear #javascript #advancedjs #interviewprep #frontend #softwareengineering

Mastering Getters and Setters in JavaScript Getters and Setters offer several benefits including encapsulation, control over property access, and adding validation without changing how the property is used. In this post, we'll focus on that last benefit: how to add validation without altering how a property is accessed. 🟦 Creating an object Let’s start with a simple object: const product = { name: "Keyboard", price: 50, }; The potential issue is JavaScript doesn't enforce any rules here so we can do this: product.price = -10; This is invalid (because price can't be a negative value) but allowed so can silently break our application logic. To add validation without changing how the property is used, we can use Getters and Setters. 🟦 Getters Getters allow us to define logic that runs when a property is read while still using it like a normal property. const product = { name: "Keyboard", _price: 50, get price() { return this._price; }, }; Now we can access it like this: console.log(product.price); and this triggers the getter. To handle validation when assigning a value, we'll use a Setter next. 🟦 Setters Setters run code when a property is assigned a value. This is great for adding validation. const product = { ... set price(value) { if (typeof value !== "number" || value < 0) { throw new Error("Price must be a non-negative number"); } this._price = value; }, }; Now, when we do: product.price = 80; It checks the value before assigning it. If the value is invalid: product.price = -10; It throws an error. This keeps our data safe without changing how the property is used. 🟦 Summary 🔹 Getters - Control how a property is accessed 🔹 Setters - Control how a property is assigned Together, they help us write cleaner, safer, and more maintainable JavaScript code. #frontend #javascript #getters #setters

𝐔𝐬𝐢𝐧𝐠 𝐧𝐞𝐰 𝐢𝐧 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 — 𝐰𝐡𝐞𝐧 𝐭𝐨 𝐮𝐬𝐞 𝐢𝐭 𝐚𝐧𝐝 𝐰𝐡𝐞𝐧 𝐧𝐨𝐭 𝐭𝐨 • JavaScript has fundamental objects  - (formerly called built-in or native objects) • These are NOT primitive types They are object representations layered on top of primitives • Use new with these fundamental objects – 𝐎𝐛𝐣𝐞𝐜𝐭 – 𝐀𝐫𝐫𝐚𝐲 – 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧 – 𝐃𝐚𝐭𝐞 – 𝐑𝐞𝐠𝐄𝐱𝐩 – 𝐄𝐫𝐫𝐨𝐫 • Date is the most important case  - There is no date literal in JavaScript  - Creating dates requires new Date • Do NOT use new with these – 𝐒𝐭𝐫𝐢𝐧𝐠 – 𝐍𝐮𝐦𝐛𝐞𝐫 – 𝐁𝐨𝐨𝐥𝐞𝐚𝐧 • Why you should avoid new String / Number / Boolean  - They create object wrappers instead of primitives  - This leads to confusing behavior and bugs • These should be used as functions, not constructors • They are best used for type coercion, not object creation • Example use case  - Converting values (like JSON data) into strings or numbers  - This is where String, Number, and Boolean shine 𝐑𝐮𝐥𝐞: 👉 𝐔𝐬𝐞 𝐧𝐞𝐰 𝐨𝐧𝐥𝐲 𝐟𝐨𝐫 𝐟𝐮𝐧𝐝𝐚𝐦𝐞𝐧𝐭𝐚𝐥 𝐨𝐛𝐣𝐞𝐜𝐭𝐬 (𝐎𝐛𝐣𝐞𝐜𝐭, 𝐀𝐫𝐫𝐚𝐲, 𝐃𝐚𝐭𝐞, 𝐞𝐭𝐜.) 👉 𝐔𝐬𝐞 𝐒𝐭𝐫𝐢𝐧𝐠, 𝐍𝐮𝐦𝐛𝐞𝐫, 𝐚𝐧𝐝 𝐁𝐨𝐨𝐥𝐞𝐚𝐧 𝐰𝐢𝐭𝐡𝐨𝐮𝐭 𝐧𝐞𝐰 𝐟𝐨𝐫 𝐜𝐨𝐞𝐫𝐜𝐢𝐨𝐧 Follow HAREESH BHITTAM for more JavaScript internals and edge cases. #JavaScript #Fundamentals #CleanCode #Frontend #YouDontKnowJS

The "One-Hit Wonder" of JavaScript: Why developers still use the IIFE. 🚀 What is an IIFE? An 𝐈𝐈𝐅𝐄 (Immediately Invoked Function Expression) is a JavaScript function that runs as soon as it is defined. Unlike a normal function that you define first and call later, an IIFE executes automatically the moment the JavaScript engine reads it. Most functions wait to be called. The 𝐈𝐈𝐅𝐄 (Immediately Invoked Function Expression) runs the exact moment it is defined. But why would you need a function that runs only once? The answer is 𝐏𝐫𝐢𝐯𝐚𝐜𝐲. 🛡️ Before modern block scoping (`let`/`const`), IIFEs were the standard way to create a private scope. Even today, they are a powerful design pattern for specific scenarios. 𝟒 𝐓𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥 𝐔𝐬𝐞 𝐂𝐚𝐬𝐞𝐬 𝐟𝐨𝐫 𝐈𝐈𝐅𝐄𝐬: 1️⃣ 𝐓𝐡𝐞 𝐌𝐨𝐝𝐮𝐥𝐞 𝐏𝐚𝐭𝐭𝐞𝐫𝐧 (𝐄𝐧𝐜𝐚𝐩𝐬𝐮𝐥𝐚𝐭𝐢𝐨𝐧) You can use an IIFE to create "private" variables that cannot be accessed from the outside, while returning only the methods you want to expose (Public API). 2️⃣ 𝐓𝐨𝐩-𝐋𝐞𝐯𝐞𝐥 𝐀𝐬𝐲𝐧𝐜/𝐀𝐰𝐚𝐢𝐭 Before ES Modules allowed top-level await, an 𝐀𝐬𝐲𝐧𝐜 𝐈𝐈𝐅𝐄 was the standard way to run asynchronous setup code immediately: `(async () => { await db.connect(); })();` 3️⃣ 𝐀𝐯𝐨𝐢𝐝𝐢𝐧𝐠 𝐆𝐥𝐨𝐛𝐚𝐥 𝐍𝐚𝐦𝐞𝐬𝐩𝐚𝐜𝐞 𝐏𝐨𝐥𝐥𝐮𝐭𝐢𝐨𝐧 Variables declared inside an IIFE stay inside. They don't leak out and overwrite variables in the global `window` object, preventing bugs in large codebases. 4️⃣ 𝐒𝐚𝐟𝐞 𝐈𝐧𝐢𝐭𝐢𝐚𝐥𝐢𝐳𝐚𝐭𝐢𝐨𝐧 Need to run complex logic just to set a single `const` value? Wrap that logic in an IIFE and return the result. It keeps your code clean and your variables constant. Check out the visual breakdown below! 👇 Do you use Async IIFEs in your projects, or have you moved fully to ES Modules? #JavaScript #WebDevelopment #CodingPatterns #SoftwareEngineering #Frontend #BestPractices

One of the most common bugs in JavaScript and React comes from copying objects the wrong way 😅 Shallow Copy vs Deep Copy In JavaScript, when you copy an object using the spread operator (...), you are only creating a shallow copy. Example: ``` const user = { name: “Ali”, skills: [“JS”, “React”] }; const copy = { …user }; copy.skills.push(“Node”); console.log(user.skills); // [“JS”, “React”, “React”, “Node”] ``` Why did the original object change? Because: • name was copied • but skills is still pointing to the same array in memory Both user.skills and copy.skills reference the same place. To create a real independent copy, use: const deepCopy = structuredClone(user); Now changing deepCopy will not affect user. 📌 In React, this mistake can cause: • state bugs • missing re-renders • very confusing UI issues Understanding how memory and references work is a game changer. #JavaScript #React #Frontend #WebDevelopment #Programming

JavaScript Hoisting: The Concept That Separates “I use JS” from “I understand JS” Hoisting is one of those JavaScript behaviors that silently explains why some code works, and why some bugs are so hard to catch. In JavaScript, code runs in two phases: 1️⃣ Compilation (creation) phase 2️⃣ Execution phase During compilation, JavaScript sets up memory for variables and functions. This is where hoisting happens. 🔹 var hoisting Only the declaration is hoisted, not the initialization. ex: console.log(x); // undefined var x = 5; Behind the scenes, JavaScript treats it like: var x; console.log(x); x = 5; No error, but also no value yet. This behavior has caused countless subtle bugs in real-world apps. 🔹 Function declarations Function declarations are fully hoisted, name and body. sayHello(); // works function sayHello() { console.log("Hello"); } This is why function declarations behave differently from function expressions. 🔹 let & const (ES6) They are hoisted, but not initialized. Accessing them before declaration throws a ReferenceError. console.log(y); // ReferenceError let y = 10; This period is known as the Temporal Dead Zone (TDZ), a design choice to make code safer and more predictable. 💡 Why this matters in real projects - Explains unexpected undefined - Helps debug scope-related issues - Shows you understand how JS actually works under the hood 📌 Best practice Don’t rely on hoisting. Write code that’s clear, intentional, and predictable, your future self (and your team) will thank you. #JavaScript #Frontend #WebDevelopment #SoftwareEngineering #CleanCode

Why JavaScript’s 'this' causes bugs — and how lexical scope saves you In JavaScript, variables and this follow different rules. Mixing them up is a common source of production bugs. const name = "Global"; const obj = {  name: "Object",  show() {   console.log(name);    // lexical scope   console.log(this.name); // this context  } }; obj.show(); const fn = obj.show; fn(); Output: --------- Global Object Global undefined name uses lexical scope --> decided by where the code is written this.name uses dynamic context --> decided by how the function is called Real production issue This often breaks code in: setTimeout / setInterval Event handlers Callbacks passed to libraries That’s why modern JavaScript prefers: Pure functions,Closures,Arrow functions Simple rule Variables use lexical scope 'this' depends on how a function is called. #javascript #webdevelopment #frontend #cleanCode #lexicalScope #thisKeyword

JavaScript Fundamentals – How Type Conversion Works Internally ⚙️ JavaScript often surprises people with results like: "5" + 1 → 51 "5" - 1 → 4 This happens because of Type Conversion (also called Type Coercion). JavaScript automatically converts values from one type to another when needed. There are two types of conversion: 1️⃣ Implicit Type Conversion (Automatic) JS converts types on its own. Examples: • + operator prefers strings → "5" + 1 becomes "51" • -, *, / prefer numbers → "5" - 1 becomes 4 2️⃣ Explicit Type Conversion (Manual) When we intentionally convert types. Examples: • Number("10") → 10 • String(10) → "10" • Boolean(0) → false Internally, JS follows rules like: • Strings dominate with + • Math operators convert values to numbers • Falsy values (0, "", null, undefined, NaN, false) convert to false Why does this matter? Understanding type conversion helps you: • Avoid unexpected bugs • Write predictable logic • Read other people’s JS code confidently • Perform better in interviews Learning JS fundamentals one concept at a time 🚀 #JavaScript #FrontendDevelopment #WebDevelopment #LearningInPublic

So, you wanna get a grip on JavaScript. It's all about functions and objects, really. They're the building blocks. A function is like a recipe - it's a set of instructions that does something, and you can use it over and over. You can make functions in a few different ways: - the classic function declaration, - function expressions, which are kinda like assigning a function to a variable, - and then there's the arrow function, which is like a shorthand way of doing things. For example, you can use functions like this: console.log(greet("Ajmal")); - it's like calling a friend to say hello. Or, you can create a function that adds two numbers together, like this: const add = function (a, b) { return a + b; }; - it's basic, but it works. And then there's the arrow function, which is super concise, like this: const multiply = (a, b) => a * b; - it's like a quick math trick. Objects, on the other hand, are like containers - they store data in key-value pairs, so you can keep things organized. It's like having a toolbox, where you can store all your functions and data in one place. You can use objects to make your code more manageable, and that's a beautiful thing. Check out this article for more info: https://lnkd.in/gTMkkSGP #JavaScript #Functions #Objects

So JavaScript has this thing called hoisting. It's like a behind-the-scenes magic trick. Variables and functions get moved to the top of their scope. This happens way before the code actually runs, during the memory creation phase. Only the declarations get hoisted, not the actual values. Think of it like setting up a stage - you're just putting the props in place, but not actually using them yet. JavaScript runs in two phases: memory creation and code execution. During the memory creation phase, variables declared with var are like empty boxes - they're initialized with undefined. Function declarations, on the other hand, are like fully formed actors - they're stored in memory, ready to go. This means you can access variables before you've even assigned a value to them. It's like trying to open an empty box - you'll just get undefined. But if you try to access a variable that doesn't exist at all, JavaScript will throw a ReferenceError - it's like trying to open a box that's not even there. Here's the thing: function declarations are fully hoisted, so you can call them before they're even declared. But function expressions are like variables - they're hoisted as undefined, so trying to call them as a function will throw a TypeError. For example, consider this code: var x = 7; function getName() {...}. You can call getName() before it's declared, and it'll work just fine. But if you try to access x before it's assigned a value, you'll just get undefined. It's all about understanding how hoisting works in JavaScript. Check out this article for more info: https://lnkd.in/g_Jh4Vd8 #JavaScript #Hoisting #Coding