JavaScript Functions: Understanding Closures and Lexical Scope

Lately, I’ve been going deeper into JavaScript coercion, and the more I study it, the less random JavaScript feels. A lot of behaviour that looks strange at first starts making sense once you realise that JavaScript is following rules defined in the ECMAScript specification. Recently, I focused on the abstract operations behind conversion, especially: - ToNumber - StringToNumber - ToString - ToPrimitive - OrdinaryToPrimitive One of the biggest takeaways for me is that JavaScript does not just “guess” what to do with values. It follows a defined process depending on the operation being performed. For example: - `"5" - 1` works because subtraction expects numbers. - `Number("")` becomes `0`. - `Number(undefined)` becomes `NaN`. - `ToNumber(BigInt)` throws an error, but `ToString(BigInt)` works. - When an object is involved, JS first tries to extract a primitive value before continuing coercion The part I found especially interesting was object-to-primitive conversion. If JavaScript encounters an object in a coercion context, it first checks for `Symbol.toPrimitive`. If that is not available, it falls back to `OrdinaryToPrimitive`, where the order of calling `toString()` and `valueOf()` depends on the hint being used: - string hint → toString() first - number hint → valueOf() first I also learned more about why string-to-number conversion behaves the way it does: - Number("25") gives 25 - Number(" 25 ") also gives 25 - Number("Infinity") gives Infinity - Number("1_000") gives NaN - Number("10n") gives NaN What is changing my understanding the most is this: - Instead of memorising “weird JavaScript behaviour”, I’m now trying to ask: 1. What operation is being performed? 2. What type of value does that operation expect? 3. Which abstract operation is JavaScript using behind the scenes? That mindset makes the language much easier to reason about. I’ve also been maintaining detailed notes on what I’m learning. If anyone wants to go deeper into these topics, I’ve uploaded them here: GitHub repo: https://lnkd.in/ephuZ-w6 #JavaScript #TypeScript #WebDevelopment #SoftwareEngineering #ECMAScript #100DaysOfCode

🚀 JavaScript Simplified Series — Day 10 Most beginners get confused when they hear this: 👉 “Functions can take other functions as input.” Wait… what? 🤯 Yes. In JavaScript, functions are first-class citizens. That means: ✔ You can store them in variables ✔ Pass them as arguments ✔ Return them from other functions And this leads to two very powerful concepts: 👉 Callback Functions 👉 Higher Order Functions 🔹 1. Callback Functions (Function inside a function) A callback is simply a function that is passed into another function and executed later. Let’s understand with a simple example 👇 function greet(name) { console.log("Hello " + name) } function processUser(name, callback) { callback(name) } processUser("Abhay", greet) 👉 Output: Hello Abhay 🔍 What’s happening here? greet is a function We pass it into processUser Inside processUser, we call it → callback(name) 📌 So, greet becomes a callback function 💡 Real-life example: Ordering food online 🍔 You place an order → wait When food is ready → delivery happens 👉 That “what happens next” is a callback 🔹 2. Higher Order Functions (Functions that use functions) A Higher Order Function (HOF) is a function that: ✔ Takes another function as input OR ✔ Returns a function Example 👇 function calculate(a, b, operation) { return operation(a, b) } function add(x, y) { return x + y } console.log(calculate(5, 3, add)) 👉 Output: 8 🔍 Breakdown: calculate is a Higher Order Function It takes operation (a function) as input Then calls it → operation(a, b) 📌 This makes your code flexible and reusable 💡 Real-life example: Think of a calculator 🧮 You give: numbers + operation Calculator decides what to do 👉 That’s exactly how HOF works 🔥 Where are these used? You already use them daily without realizing: [1, 2, 3].map(num => num * 2) 👉 map() is a Higher Order Function 👉 (num => num * 2) is a callback 🔥 Simple Summary Callback → function passed into another function Higher Order Function → function that uses other functions 💡 Programming Rule Functions are not just code… They are values you can pass around. If you want to learn JavaScript in a simple and practical way, you can follow these YouTube channels: • Rohit Negi • Hitesh Choudhary (Chai aur Code) 📌 Series Progress Day 1 → What is JavaScript Day 2 → Variables & Data Types Day 3 → Type Conversion & Operators Day 4 → Truthy & Falsy + Comparison Operators Day 5 → If Else + Switch + Ternary Day 6 → Loops Day 7 → Break + Continue + Nested Loops Day 8 → Functions Basics Day 9 → Arrow + Default + Rest Parameters Day 10 → Callback & Higher Order Functions Day 11 → Arrays (Next Post) Follow for more 🚀 #JavaScriptSimplified #javascript #webdevelopment #coding #programming #learninpublic #100DaysOfCode #frontenddevelopment #devcommunity #codingjourney #softwaredeveloper #techcommunity #dailylearning #codeeveryday

Yesterday, I went deeper into one of the most confusing parts of JavaScript: "The + operator" At first glance, `+` looks simple. But unlike operators such as -, *, and /, JavaScript’s + has two possible meanings: - numeric addition - string concatenation And that is exactly what makes it tricky. My biggest takeaway was this: 1. When JavaScript sees a + b, it does not immediately assume numeric addition. 2. It first has to decide: - Should this be string concatenation? - Or should this be numeric addition? That decision is what makes "+" so different from operators like "-". For example: - "5" - 1 gives 4 because subtraction is numeric only. But: - "5" + 1 gives "51" because once JavaScript sees that one side becomes a string, it goes down the string concatenation path. I also learned that the real logic of + is deeper than the small operator section most people look at first. The actual mental model I now use is: 1. Convert both sides to primitives 2. If either primitive is a string: - convert both to strings - concatenate Otherwise: - convert both to numeric values - make sure the numeric types match - perform numeric addition That also led me into learning ToNumeric, which was another big insight. Before this, I mostly thought in terms of ToNumber, but ToNumeric is different: - ToNumber only gives a Number - ToNumeric can return either a Number or a BigInt That is why: - 1n + 2n works but - 1 + 2n throws a TypeError because JavaScript does not allow mixing Number and BigInt in that numeric path. The more I study coercion, the more I realise that JavaScript is not random at all. A lot of “weird” behavior starts making sense when you stop memorising examples and instead ask: - what operation is being performed? - what kind of value does it need? - which abstract operation is JavaScript using behind the scenes? That shift in mindset is making the language far more understandable for me. I’ve also been maintaining detailed notes on everything I’m learning. If anyone wants the deeper breakdown with examples and spec-based notes, I’ve uploaded them here: GitHub repo: https://lnkd.in/ephuZ-w6 Next, I’ll keep going deeper into coercion and loose equality. #JavaScript #TypeScript #WebDevelopment #SoftwareEngineering #ECMAScript #100DaysOfCode

When I started learning JavaScript, async code felt unpredictable. Things didn’t execute in order. Logs appeared out of nowhere. And promises felt like “magic”. The real issue? I didn’t understand callbacks. Everything in async JavaScript builds on top of them. So I wrote this article to break it down clearly: 👉 Execution flow 👉 Sync vs async callbacks 👉 Why they still matter in modern code If async JS has ever felt confusing, this will help. https://lnkd.in/g7DJ7yXX #JavaScript #LearningToCode #Callbacks #SoftwareDevelopment

I’ve been writing JavaScript for around 2.6 years now, and looking back, there are a few things I really wish someone had just shown me. Not advanced stuff—just the “why didn’t I know this earlier?” kind of basics 👇 ━━━━━━━━━━━━━━━━━━━ 1️⃣ Optional Chaining (?.) I used to write checks like: if (user && user.profile && user.profile.name) Now it’s just: user?.profile?.name Feels small, but it removes so much noise from the code. ━━━━━━━━━━━━━━━━━━━ 2️⃣ Nullish Coalescing (??) I used to do: const name = user.name || "Guest" But that breaks when value is 0 or empty string. Now: const name = user.name ?? "Guest" This one saved me from so many weird bugs. ━━━━━━━━━━━━━━━━━━━ 3️⃣ Destructuring Earlier: const name = user.name const age = user.age Now: const { name, age } = user Simple change… but code becomes so much easier to scan. ━━━━━━━━━━━━━━━━━━━ 4️⃣ Promise.all() I didn’t realize how slow my code was until I learned this. Instead of waiting one by one: await fetchUsers() await fetchProducts() Now: Promise.all([...]) Everything runs together. Much faster response time. ━━━━━━━━━━━━━━━━━━━ 5️⃣ console.table() This one is underrated. Instead of messy logs everywhere, just: console.table(data) Clean rows, clean columns. Debugging becomes less painful. ━━━━━━━━━━━━━━━━━━━ Nothing fancy here. But honestly, these small things quietly level up your everyday coding. ━━━━━━━━━━━━━━━━━━━ If you’re just starting out, I’d focus on these before jumping into frameworks. They stick with you everywhere — React, Node, anything. ━━━━━━━━━━━━━━━━━━━ What about you? Which one did you start using first? 👇 #JavaScript #WebDevelopment #MERNStack #ReactJS #NodeJS #CodingLife #LearnToCode

🚀 How does a JavaScript file actually "work"? (A Beginner’s Guide) If you’re just starting your coding journey, JavaScript can feel like magic. You write a few lines in a .js file, open the browser, and things start moving! But what is happening behind the scenes? Let’s break it down using a simple Kitchen Analogy 🍳: 1. The Creation Phase (Setting the Table) 🧠 Before the "cooking" starts, the JavaScript Engine (the Chef) scans your entire file. It looks at all your variables and functions. It sets aside "plates" (memory) for them. At this stage, your variables are empty (undefined), but the Chef knows they are coming. This is what developers call Hoisting. 2. The Execution Phase (The Cooking) ⚙️ Now, the Chef starts reading your code line-by-line, from top to bottom. It puts the "ingredients" (values) into the "plates" (variables). It executes commands one by one. Important Note: JavaScript is a Single-threaded language. This means the Chef has only two hands and can only do one task at a time! 3. The Call Stack (The Order List) 📚 Think of the Call Stack as a stack of orders. When you call a function, it’s like a new order ticket being pinned up. Once the function is finished, the ticket is ripped off and thrown away. If you give too many orders at once, the stack gets "overflowed"! 4. The Event Loop (The Assistant) 🔄 What if you’re waiting for water to boil (like fetching data from a server)? The Chef doesn't just stand there! The Chef moves the "waiting task" to the side and keeps working on other orders. The Event Loop is like a smart assistant who watches the boiling water and tells the Chef, "Hey, it's ready!" only when the Chef is free. You don't need to be a genius to understand JavaScript; you just need to understand the process. Once you know how the "Chef" thinks, debugging becomes much easier! Are you a beginner struggling with a specific JS concept? Drop your questions below—let's learn together! 👇 #JavaScript #CodingBeginner #WebDevelopment #Programming101 #TechCommunity #SoftwareEngineering #LearnToCode #JSBasics #FullStackDeveloper #CareerTips

Day 3/30 — JavaScript Journey JavaScript Conditionals (if / else, switch) Today your code learns to DECIDE. 🧠 Most beginners write code that runs. Great developers write code that thinks. 🔥 The Core Idea Conditionals turn JavaScript from a calculator into a decision engine. Your code stops doing everything… and starts doing the right thing at the right time. ⚡ if / else → Real-Time Decisions Use this when logic is dynamic and complex. if (user.isLoggedIn) {  showDashboard(); } else {  redirectToLogin(); } 👉 Reads like human thinking: “If this is true → do this, otherwise → do that.” ⚡ else if → Multiple Paths if (score > 90) {  grade = "A"; } else if (score > 75) {  grade = "B"; } else {  grade = "C"; } 👉 Your code evaluates top → bottom First match wins. Execution stops. ⚡ switch → Clean Structured Decisions Best when comparing one value against many options switch (role) {  case "admin":   access = "full";   break;  case "user":   access = "limited";   break;  default:   access = "guest"; } 👉 Cleaner than multiple else if 👉 Faster to scan, easier to maintain ⚠️ Critical Concepts (Most People Miss This) • Truthiness matters if ("0") // true 😳 if (0)  // false • === vs == 5 == "5"  // true (loose) 5 === "5" // false (strict) 👉 Always prefer === (predictable behavior) • Missing break in switch = fall-through bug case "admin":  access = "full"; // no break → next case runs too ⚠️ 🧠 Pro Insight Conditionals are not just syntax… They define your application’s behavior logic. Bad logic = bugs Good logic = clean systems 💡 When to Use What Situation Best Choice Complex logic / ranges if / else Multiple conditions else if Single variable, many values switch 🚀 Final Thought Beginners write: “Make it work” Developers evolve to: “Make it decide correctly” Because in real systems… logic is everything. If you master conditionals, you don’t just write code anymore — you control outcomes. 🔥

I used to write JavaScript like this: getData(function(a) { processData(a, function(b) { saveData(b, function(c) { console.log("done... maybe?"); }); }); }); My senior dev looked at my screen, took a deep breath, and said: "We need to talk." 😭 That was my introduction to Callback Hell — and the moment I realized I had a LOT to learn about Asynchronous JavaScript. Here's the evolution every JavaScript developer goes through: Stage 1 — Callbacks 😵 You pass functions into functions. It works. But nest 4 of them and your code looks like a pyramid of doom. Nobody wants to debug that at 2am. Stage 2 — Promises 🤝 Cleaner. Chainable. You discover .then(), .catch(), .finally() and feel like a genius. Until you chain 7 of them and wonder if this is really better. Stage 3 — Async/Await ✨ The moment everything clicks. Your async code finally reads like a story. Clean, readable, debuggable. This is where real JavaScript development begins. Stage 4 — You stop panicking about the Event Loop 🧘 You understand why JavaScript doesn't block. You understand the Call Stack, the Web APIs, the Callback Queue. And suddenly the whole language makes sense. Most developers skip understanding the why and jump straight to copying async/await from Stack Overflow. Don't be that developer. Understand the journey: Callbacks → Promises → Async/Await → Fetch API → Axios Each one exists because the previous one had a problem. Each one made us better. Save this carousel. It covers everything you need — Callbacks, Promises, Promise Chaining, Async/Await, setTimeout, Event Listeners, Fetch API, Axios, and XHR — all with real code examples. Whether you're just starting out or brushing up before an interview, this one's for you. 🚀 Drop a 🔥 in the comments if async JS once broke your brain — and tell me which stage you're currently at! #JavaScript #WebDevelopment #AsyncJavaScript #Programming #100DaysOfCode #CodeNewbie #SoftwareEngineering #Frontend #LearnToCode #JavaScriptTips #TechEducation #Coding #DevCommunity #FrontendDevelopment #CareerInTech

I published a book today. JavaScript: The Parts It is a foundational guide to JavaScript for developers who learned the language by imitation — who can build things, ship things, and make things work, but struggle to explain what their code is actually doing. That was me for longer than I'd like to admit. I learned JavaScript the way most people do: tutorials, patterns, copy-paste until it runs. I could produce output. I couldn't always explain it. When someone asked me in an interview to describe what my code was doing, the words weren't there — because the understanding that would produce those words wasn't there either. This book is what I wish had existed when I was starting out. It uses a method called PARTS — Problem, Answer, Reasoning, Terms, Syntax — to introduce every concept in the order that actually builds understanding, rather than the order that just gets code to run. It's technically precise without being dense. And it's honest about what it's like to feel like you're faking it, and why that feeling has a specific cause and a specific fix. It's available now on Leanpub, and it's the first book in a planned series covering the full self-taught developer curriculum. 👉 leanpub.com/jsparts If you know a developer who's been coding for years but still feels like they're faking it — this is for them.