Understanding "this" in JavaScript: A Bollywood Analogy

Closures in JavaScript — Full Bollywood Vibes Edition 🍿 In JavaScript, Closure is like that mystery character in a movie — quiet at first, but once you understand it, you realize, “picture toh ab samajh mein aayi!” 😎 Let’s break it down with some filmy style 👇 --- 💡 What is a Closure? Closure is when a function remembers its lexical scope — even after the outer function has finished execution. Or simply put: > “Jo baat andar hoti hai, wo andar hi rehti hai!” (— Gangs of Wasseypur vibes) 😜 Example 👇 function makeHero(name) { return function dialogue() { console.log(`${name} — kabhi kabhi lagta hai apun hi bhagwan hai!`); }; } const hero = makeHero("Hemant"); hero(); // Hemant — kabhi kabhi lagta hai apun hi bhagwan hai! Even after makeHero finishes, the inner function still remembers name. That memory = Closure! 🧠 --- 🎭 Closures Are Everywhere! When you use: setTimeout event listeners callback functions or React hooks (useState/useEffect) Closures are silently doing their work behind the scenes! Just like a background character holding the movie together without getting the spotlight 🎥 > “Main hoon na… bas dikhta nahi hoon.” (— SRK style) 😅 --- ⚙️ Another Example — Private Variables Closures help you create private data 👇 function bankAccount() { let balance = 1000; return { deposit(amount) { balance += amount; console.log(`Balance: ₹${balance}`); }, withdraw(amount) { balance -= amount; console.log(`Balance: ₹${balance}`); }, }; } const myAcc = bankAccount(); myAcc.deposit(500); // ₹1500 myAcc.withdraw(200); // ₹1300 Here, balance can’t be accessed directly — it’s safe inside the closure 🔒 > “Jo andar gaya, wo bahar nahi aata.” (— Hera Pheri energy 💸) --- 💬 In short: Closures = Memory + Power They let your inner functions remember data long after the scene is over. Or as our hero would say: > “Don ko pakadna mushkil hi nahi… impossible hai!” — And same goes for understanding JS deeply without knowing closures 😉 --- #JavaScript #Closures #WebDevelopment #CodingHumor #Frontend #LearningIsFun #Bollywood

“Why does this behave so weird in JavaScript? 🤯 Let’s finally make sense of it!” If you’ve ever shouted at your screen because this suddenly became undefined — you’re not alone 😅 Let’s break down how this works across different scenarios with simple examples 👇 🧩 1️⃣ Arrow Function Defined Directly in Object const person = { name: "Suverk", greet: () => console.log(`Hi ${this.name}`) }; person.greet(); // ❌ undefined 🧠 Why? Arrow functions don’t have their own this. They lexically inherit this from their surrounding scope — which here is the global (not person). ✅ Fix: Use a regular function: greet() { console.log(`Hi ${this.name}`); } 🧩 2️⃣ Arrow Function Inside a Regular Method const person = { name: "Suverk", greet: function() { const arrow = () => console.log(this.name); arrow(); } }; person.greet(); // ✅ "Suverk" 🧠 Why? The arrow function inherits this from where it was created — inside greet, and this inside greet = person. ✅ Works perfectly because of lexical scoping. 🧩 3️⃣ Regular Function Inside Another Regular Function const person = { name: "Suverk", greet: function() { function inner() { console.log(this.name); } inner(); } }; person.greet(); // ❌ undefined 🧠 Why? When you call inner() as a plain function, it’s not attached to any object. So this defaults to global (or undefined in strict mode). ✅ Fixes: // Option 1 const self = this; function inner() { console.log(self.name); } // Option 2 function inner() { console.log(this.name); } inner.bind(this)(); // Option 3 const inner = () => console.log(this.name); 🧩 4️⃣ Detached Method Reference const person = { name: "Suverk", greet() { console.log(this.name); } }; const use = person.greet; use(); // ❌ undefined 🧠 Why? this depends on how a function is called. You’ve just taken the function reference — the link to person is gone. ✅ Fix: const use = person.greet.bind(person); use(); // ✅ "Suverk" In JavaScript, this depends on how a function is called — except for arrow functions, which depend on where they’re defined. 💬 Have you ever been tricked by this before? Drop your comment below 👇 — let’s make others learn faster than we did 😅 #JavaScript #Frontend #WebDevelopment #Angular

JavaScript evolves every year — but many devs still use it like it’s 2016. 🚀 Here are 5 underrated modern features that can simplify your code instantly: Optional chaining ?. Nullish coalescing ?? Array.at() Object.hasOwn() Intl for formatting 1️⃣ Optional Chaining (?.) 💡 Use Case: Access nested properties safely without breaking your code. const user = { profile: { name: 'Akhila' } }; console.log(user.profile?.name); // ✅ 'Akhila' console.log(user.address?.city); // ✅ undefined (no error) 🧠 No more Cannot read property 'x' of undefined errors. 2️⃣ Nullish Coalescing (??) 💡 Use Case: Provide fallback values only for null or undefined. const score = 0; console.log(score ?? 100); // ✅ 0 (unlike || which would return 100) ⚡ Keeps false, 0, and '' valid — great for numeric or boolean defaults. 3️⃣ Array.at() 💡 Use Case: Access elements from the end of an array more cleanly. const fruits = ['🍎', '🍌', '🍇']; console.log(fruits.at(-1)); // ✅ '🍇' (last element) 🍉 Replaces clunky fruits[fruits.length - 1] syntax. 4️⃣ Object.hasOwn() 💡 Use Case: Check if an object directly has a property (safer than hasOwnProperty). const obj = { name: 'JS' }; console.log(Object.hasOwn(obj, 'name')); // ✅ true 🛡️ Cleaner and avoids prototype pollution issues. 5️⃣ Intl (Internationalization API) 💡 Use Case: Format dates, numbers, and currencies globally. const price = new Intl.NumberFormat('en-IN', { style: 'currency', currency: 'INR' }).format(9999.5); console.log(price); // ✅ ₹9,999.50 🌍 Perfect for apps with multi-language or multi-region users. ✨ Small features, big clarity. Which of these do you use the most (or plan to start using)? #JavaScript #WebDevelopment #CodingTips #Frontend #TechTrends

💛 #JSMadeEasy with Virashree When I first heard about “Hoisting” in JavaScript, I thought it had something to do with lifting variables up 🏋️♀️😂 Turns out… I wasn’t entirely wrong! - Here’s a simple way to understand what Hoisting really means 👇 🧠 What is Hoisting? - When JavaScript runs your code, it does it in two phases: 1️⃣ 𝗠𝗲𝗺𝗼𝗿𝘆 𝗖𝗿𝗲𝗮𝘁𝗶𝗼𝗻 𝗣𝗵𝗮𝘀𝗲 — where it scans and “remembers” all variables and functions 2️⃣ 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗣𝗵𝗮𝘀𝗲 — where it actually runs the code line by line - In the first phase, JS “hoists” (lifts) all variable and function declarations to the top of their scope. 💻 Example 1: Using var console.log(name); // undefined var name = "Virashree"; JS internally does this 👇 var name; // declaration hoisted console.log(name); // undefined name = "Virashree"; - So, name exists in memory but has no value yet — hence undefined. 🌿 Example 2: Using let and const console.log(age); // ❌ ReferenceError let age = 24; - Unlike var, let and const are hoisted too — but they stay in a special zone called the 𝗧𝗲𝗺𝗽𝗼𝗿𝗮𝗹 𝗗𝗲𝗮𝗱 𝗭𝗼𝗻𝗲 (𝗧𝗗𝗭) until they’re declared. - That’s why accessing them before declaration throws an error instead of showing undefined. ⚙️ Function Hoisting — Two Types In JavaScript, there are two main ways to create functions: 1️⃣ Function Declaration 2️⃣ Function Expression - And they behave very differently when it comes to hoisting 👇 🌿 1. 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻 𝗗𝗲𝗰𝗹𝗮𝗿𝗮𝘁𝗶𝗼𝗻 — Fully Hoisted ✅ The whole function is hoisted to the top of its scope. So you can call it before it’s defined. greet(); // ✅ Works fine function greet() {  console.log("Hello, Virashree!"); } ➡️ Output: Hello, Virashree! Because JS hoists both the name and the body of the function. 🌸 2. 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻 𝗘𝘅𝗽𝗿𝗲𝘀𝘀𝗶𝗼𝗻 — NOT Fully Hoisted When you assign a function to a variable (using var, let, or const), only the variable name is hoisted — not the function itself. sayHi(); // ❌ TypeError var sayHi = function() {  console.log("Hi there!"); }; - If you used var, you’ll get: ❌ TypeError: sayHi is not a function - If you used let or const, you’ll get: ❌ ReferenceError: Cannot access 'sayHi' before initialization - So basically: 🚫 The variable gets hoisted, but the actual function definition does not. 🧩 Quick Recap var      → Hoisted ✅ | Value: undefined let      → Hoisted ✅ | Value: ❌ ReferenceError (TDZ) const     → Hoisted ✅ | Value: ❌ ReferenceError (TDZ) function decl → ✅ Fully hoisted function expr → ⚠️ Partially hoisted (variable only) 🧠 Takeaway - So next time your code throws “is not a function,” - check how you declared it — not where! 😉 💬 Question for you: Which one confused you more — function declarations or function expressions? Comment below and I’ll break it down in my next #javascript #frontenddevelopment #webdevelopment #reactjs #learninginpublic #womenintech

'Question' Can JavaScript and Rust Really Be Compared? I’ve seen this question pop up often — and it’s a good one. At first glance, JavaScript and Rust seem worlds apart. But with the rise of WebAssembly (Wasm), that gap is shrinking fast. Let’s unpack this 👇 ⚙️ Different Roots, Different Strengths JavaScript was built for flexibility — it powers most of the web, both on the front and back end (thanks to Node.js). Rust was built for precision — it’s all about safety, performance, and control over memory. JS gives you speed of development. Rust gives you speed of execution. 🧩 How They Think About Memory JavaScript: Uses garbage collection. You don’t worry about memory — but sometimes pay for it in performance. Rust: Enforces memory safety at compile time. You manage ownership and lifetimes — and the compiler keeps you honest. It’s the difference between “it just works” and “it works, and I can prove it.” 🚀 Performance and Real Use Rust compiles to machine code. It’s as fast as C++, used in browsers, crypto, and embedded systems. JS is interpreted or JIT-compiled. It’s slower in computation-heavy tasks, but unbeatable for interactive web work. 🌐 Where They Shine Use Case JavaScript | Rust Front-end web ✅ | 🚫 (except via WebAssembly) Back-end APIs ✅ | ⚙️ (via Axum, Actix) Game engines / native apps ⚙️ | ✅ Embedded systems 🚫 | ✅ Performance-critical code 🚫 | ✅ Rapid prototyping ✅ | ⚙️ 🔗 Where They Meet: WebAssembly This is where things get exciting. Rust can compile to Wasm, and JavaScript can call that Rust code right inside the browser. That means: Rust handles the heavy computation (e.g., image processing, encryption). JavaScript handles the UI, interactivity, and web logic. A Tiny Example Here’s a simple example that calculates Fibonacci numbers in Rust — and runs in JS via WebAssembly. Rust (src/lib.rs): #[no_mangle] pub extern "C" fn fibonacci(n: u32) -> u32 { match n { 0 => 0, 1 => 1, _ => fibonacci(n - 1) + fibonacci(n - 2), } } Compile it with: wasm-pack build --target web JavaScript: import init, { fibonacci } from "./pkg/your_wasm_package.js"; async function run() { await init(); console.log("Fibonacci(10) =", fibonacci(10)); } run(); And just like that — Rust is doing the math, JavaScript is showing the result. Final Thought Rust and JavaScript aren’t rivals — they’re complements. One gives you safety and speed; the other gives you reach and flexibility. Together, they’re redefining what’s possible in web and systems development.

🚀 Understanding the "Single Number" Problem (LeetCode 136) In JavaScript, there’s always something new to discover — even in simple-looking problems. Recently, I revisited the Single Number challenge and explored two different approaches: using a hash table and using XOR. 💡 Approach 1: Using a Hash Table We create an object that counts how many times each number appears. If a number appears once, that’s our answer. function singleNumber(arr) { let hash = {}; // frequency map for (let i = 0; i < arr.length; i++) { if (!hash[arr[i]]) hash[arr[i]] = 1; else hash[arr[i]]++; } for (let i = 0; i < arr.length; i++) { if (hash[arr[i]] === 1) return arr[i]; } } console.log(singleNumber([2, 2, 1])); // Output: 1 ⚡ Approach 2: Using XOR (bitwise logic) This approach is faster — duplicate numbers cancel each other out, leaving only the single one. function singleNumber(arr) {  let xor = 0;  for (let i = 0; i < arr.length; i++) {   xor = xor ^ arr[i];  }  return xor; } console.log(singleNumber([4, 1, 2, 1, 2])); // Output: 4 The XOR trick is elegant . 🧠 Quick Concepts 🔸 Hash Table (Object in JS): Think of it like a locker with labels — each label (key) stores a value. You can easily count or find things using those keys. Example: let hash = {}; hash["apple"] = 2; // apple appears twice 🔸 XOR (Exclusive OR): It’s a bitwise operation that gives: 1 if bits are different 0 if bits are same 👉 Same numbers cancel out: 2 ^ 2 ^ 1 = 1 That’s why XOR is a shortcut for finding the unique number! 🎯 Takeaway: Even a small problem can teach you how counting works in objects and how bitwise logic simplifies code. Learning by doing builds real understanding 💪 #JavaScript #CodingJourney #FrontendDevelopment #DeveloperTips #LearnByDoing

Why Did 5 + "5" Give You 55 🤓? Let’s Talk About JS Type Coercion This explanation is going to make you understand why [ ] == ![ ] is equal to true If you’ve ever typed 5 + "5" in JavaScript and got "55" instead of 10, don’t worry, you didn’t break anything. You just bumped into something called Type Coercion. It’s one of those sneaky but important concepts in JavaScript that can either save you or confuse you if you don’t understand how it works. Let’s break it down together in the simplest way. So, What Is Type Coercion? JavaScript is what we call a “loosely typed” language. This means it lets you mix and match data types (like strings, numbers, booleans), and it tries to convert them automatically when needed. This automatic conversion is known as Type Coercion. It happens all the time behind the scenes, sometimes in helpful ways, sometimes in surprising ones. Two Types: Implicit and Explicit There are two main types of coercion: Implicit coercion happens when JavaScript does the converting for you (without asking). Explicit coercion happens when you do the converting on purpose using methods like String(), Number(), or Boolean(). Let’s Look at Some Real Examples ✅ Here are a few common cases where coercion shows up: ✅ 5 + "5" → "55" (number becomes a string, because + with a string means concatenate) ✅ "10" - 3 → 7 (string becomes a number, because - only works with numbers) ✅ true + 1 → 2 (boolean true becomes 1) ✅ false == 0 → true (loose equality == allows coercion) ✅ null == undefined → true (but they’re not strictly equal!) ✅ [] + 1 → "1" (array becomes an empty string, then it's concatenated) ✅ [1] + 1 → "11" (array [1] becomes "1", then string + number = string) Understand how JavaScript behaves with different value types is very crucial for building effective and bug free scalable applications. But nevertheless, you wehther you know type Coercion or not, it's always better you take precautions. How to Keep Your Code Clean and Safe To avoid surprises, always try to use strict equality (===) instead of ==, because it checks both value and type. Also, manually convert data to the correct type when needed using Number(), String(), or Boolean(). This gives you more control and fewer headaches down the line. I hope you have learnt something.

JavaScript learn 1. typeof NaN → "number" Even though NaN means “Not-a-Number”, JavaScript treats it as a number type. So typeof NaN returns "number". 2. 9999999999999999 → 10000000000000000 JavaScript uses 64-bit floating point numbers, which cannot precisely represent very large integers. 9999999999999999 gets rounded to 10000000000000000. 3. 0.5 + 0.1 == 0.6 → true This combination is precisely representable in floating point math, so it evaluates correctly. 4. 0.1 + 0.2 == 0.3 → false Floating-point precision error. 0.1 + 0.2 actually equals: 0.30000000000000004 So it is not equal to 0.3. 5. Math.max() → -Infinity With no arguments, JavaScript treats the max value as the smallest possible value: -Infinity. 6. Math.min() → Infinity With no arguments, JavaScript treats min value as the largest possible value: Infinity. 7. [] + [] → "" Both arrays convert to empty strings during concatenation: "" + "" = "". 8. [] + {} → "[object Object]" [] becomes "" {} becomes "[object Object]" Result: "" + "[object Object]". 9. {} + [] → 0 JavaScript interprets {} as an empty block, not an object. Then it converts [] to a number → 0. 10. true + true + true === 3 → true Boolean → Number conversion: true → 1 1 + 1 + 1 = 3. 11. true - true → 0 Boolean converted again: 1 - 1 = 0. 12. true == 1 → true Loose equality (==) performs type coercion: true → 1 → so 1 == 1. 13. true === 1 → false Strict equality (===) does not convert types. Boolean is not equal to number.

JavaScript Simplified: Destructuring & Spread Operator Ever noticed how JavaScript lets you write cleaner and shorter code? That’s where Destructuring and the Spread Operator (...) come in! What is Destructuring? Destructuring means “unpacking” values from arrays or objects into variables— instead of accessing each one manually. const user = { name: "Sameer", age: 22 }; const { name, age } = user; console.log(name, age); // Sameer 22 You can even rename or set default values: const { country: location = "India" } = user; What is the Spread Operator (...)? The spread operator helps you copy, merge, or expand arrays and objects effortlessly. const fruits = ["apple", "banana"]; const moreFruits = ["orange", "grapes"]; const allFruits = [...fruits, ...moreFruits]; console.log(allFruits); // ["apple", "banana", "orange", "grapes"] It also works great with objects: const user = { name: "Sameer", age: 22 }; const updatedUser = { ...user, age: 23 }; console.log(updatedUser); // { name: "Sameer", age: 23 } In short: Destructuring → Pull out values easily Spread → Copy or merge effortlessly #JavaScript #WebDevelopment #Frontend #CodingTips #Destructuring #SpreadOperator #LearnJS

💭 What do you think — will this effect run on every click? const Counter = () => { const [count, setCount] = React.useState(0); const config = { theme: "dark" }; React.useEffect(() => { console.log("Effect ran"); }, [config]); return <button onClick={() => setCount(count + 1)}>Click</button>; }; At first glance, config looks static. But… this effect will run on every single click 🧨 Let’s break down why — from JavaScript memory to React Fiber internals 👇 🧠 1. JS Basics — Reference Types In JavaScript, objects & functions are reference types — compared by memory address, not content. { a: 1 } === { a: 1 } // false () => {} === () => {} // false Every render recreates: const config = { theme: "dark" } → a new object in memory → a new reference. ⚛️ 2. Under the Hood — React Fiber When setCount triggers a re-render: React creates a new Fiber node for the current render. The previous Fiber is kept as the alternate. React compares them during reconciliation. 🔄 3. Effect Dependency Comparison React checks dependencies via: Object.is(prevDep, nextDep) Since each render creates a new config reference, the comparison fails → effect runs again. 🧩 Render 1 → config ref#1 Render 2 → config ref#2 → Object.is(ref#1, ref#2) → false → Effect runs ⚡️ 🧘♂️ 4. The Fix To prevent unnecessary re-runs, stabilize the reference: const config = React.useMemo(() => ({ theme: "dark" }), []); Or, if it’s static, define it outside the component: const config = { theme: "dark" }; ✅ Summary Each render → new Fiber node New objects/functions → new references React compares deps via Object.is(prev, next) Different refs = effect re-runs Use useMemo / useCallback to stabilize references 🔍 Takeaway: Every render isn’t just new JSX — it’s new memory, new references, and a new Fiber snapshot. Understanding that is what separates debugging React from mastering it. 🚀