JavaScript Coercion: Understanding == vs ===

The JavaScript Temporal API will soon be Baseline Newly Available. Here's a cheatsheet that I built for developers who already know Date. https://lnkd.in/emvWBw-v Enjoy!

Something small but nice I recently came across in JavaScript 👨💻✨ : String.trimEnd(). Earlier, whenever I needed to remove only the trailing spaces from a string, I used to write a small regex for it or sometimes even used .trim(). But .trim() removes both leading and trailing spaces, which isn’t always what we want — especially when the leading indentation actually matters. For example, I used to do something like this: const message = " Action Required: Clear Cache "; // Earlier approach const cleaned = message.replace(/\s+$/, ""); It works, but the regex isn’t exactly the most readable thing 🤯. Recently I noticed there’s a much cleaner native way 👇 const message = " Action Required: Clear Cache "; const result = message.trimEnd(); Now it clearly expresses the intent: remove only the trailing whitespace while keeping the start intact ✅. Result: " Action Required: Clear Cache" Small things like this make code more readable and intentional ✨, and since it’s part of modern JavaScript (along with trimStart()), there’s no need for regex hacks anymore. Sometimes the language already has the cleaner solution, we just discover it a bit later 😄🚀 #JavaScript #CodingTips #CleanCode #WebDev #WebDevelopment

The most confusing thing in JavaScript every time I go through core JS revision is 'this' Keyword? And the funny part? “this” doesn’t actually mean this. Most people think: " this = current object " Reality: 👉 this = depends on how the function is called Example: const obj = { name: "JS", say() { console.log(this.name); } }; obj.say(); // JS ✅ Now: const fn = obj.say; fn(); // undefined ❌ Same function. Different result. Why? 👉 Because this is decided at call time, not when the function is written. And then arrow functions make it worse: const obj = { name: "JS", say: () => { console.log(this.name); } }; obj.say(); // undefined 😭 👉 Arrow functions don’t have their own this 👉 They inherit it from the surrounding scope 💡 Insight: If you don’t understand this, you’re not debugging JavaScript… you’re guessing. 🎯 Rule of thumb: Regular functions → this depends on how they’re called Arrow functions → this is inherited Detached functions → this gets lost Once this clicks, JavaScript suddenly stops feeling “random”. Save this before this humbles you in production 🙂

I’ve started learning scope in JavaScript, but before diving into it, I took an interesting detour into a very important question: Is JavaScript compiled or interpreted? Before getting into scope properly, I learned that JavaScript does not behave like a simple line-by-line interpreter. A good example is this: ```js console.log("Hello"); function foo() { console....log("world"); } console.log("hello world"); ``` If JavaScript was executed in a purely naive line-by-line way, we might expect "Hello" to be logged before the error appears. But that does not happen. The script fails before execution starts because the JavaScript engine first goes through an initial preparation phase. That phase includes things like: 1. parsing the code 2. checking whether the syntax is valid 3. building an internal representation 4. preparing the code for execution So a better mental model is: Source code -> Parse / syntax check -> Internal representation / compilation steps -> Execution This helped me understand that calling JS simply “interpreted” is not the full picture. Modern JavaScript engines like V8 are much more advanced. They can parse code, create internal representations, interpret some code, compile parts into bytecode or internal instructions, and even JIT-compile frequently used parts for better performance. So JavaScript is commonly called an interpreted language, but in modern engines, the reality is more nuanced. This also connects nicely with scope. Scope is about the visibility of variables and functions in code, but before JavaScript can execute code, the engine first needs to understand the structure of that code. That means scope is not just a runtime topic. It is closely connected to how the engine reads, parses, and prepares the program. My main takeaway: JavaScript is not random, and it is not just “reading one line at a time”. There is a preparation phase before execution, and understanding that makes topics like scope, hoisting, and errors much easier to reason about. #JavaScript #TypeScript #WebDevelopment #SoftwareEngineering #V8 #LearningInPublic

Day 6: Undefined vs Not Defined in JS Today I completed the next topic in my learning journey, focusing on a concept that confuses many beginners: the difference between undefined and not defined in JavaScript. While they sound identical, they mean very different things to the JavaScript engine. When you declare a variable but do not assign it a value, JavaScript allocates memory for it during the creation phase of the execution context and automatically assigns it a special placeholder called undefined. This means the variable definitely exists, but it just does not have a value yet. On the other hand, not defined means the variable has not even been declared in your code. If you try to access a variable that the JavaScript engine cannot find anywhere in the memory allocation phase, it will throw a ReferenceError telling you that the variable is not defined. This topic also highlights why JavaScript is known as a loosely typed or weakly typed language. You do not need to specify what kind of data a variable will hold. You can assign a number to a variable, and later change it to a string or a boolean without the engine throwing an error. One major mistake to avoid is manually assigning the value undefined to a variable to clear it or mark it as empty. While JavaScript will let you do this, it is highly discouraged by the developer community. The keyword undefined is meant to be used exclusively by the JavaScript engine as a default state. If you need to explicitly state that a variable is empty, you should use null instead. Understanding these small details makes a huge difference when debugging complex applications and tracing variable states in your code. What is your favorite method for handling empty or uninitialized variables in your projects? #JavaScript #WebDevelopment #NamasteJavaScript #JSFundamentals #CodingJourney #FrontendEngineer #UndefinedVsNotDefined #CleanCode

🤔 Ever seen RangeError: Maximum call stack size exceeded and wondered what it actually means? It usually comes down to how the call stack works, how recursion grows it, and why every JavaScript engine has depth limits. 🧠 JavaScript interview question What is the call stack, why does recursion have depth limits, and what causes a stack overflow? ✅ Short answer The call stack is where JavaScript keeps track of active function calls. Every recursive call adds a new stack frame. If recursion goes too deep, or never stops, the stack fills up and throws a stack overflow error. 🔍 A bit more detail JavaScript runs code on a single thread and uses the call stack to manage function execution. When one function calls another, a new execution context is pushed onto the stack. When a function finishes, it is popped off and control returns to the caller. With recursion, this push process keeps happening until a base case stops it. That is why a correct base case matters so much. Without it, or with too many nested calls, you eventually hit the engine's stack limit and get: RangeError: Maximum call stack size exceeded Example with a safe base case: function factorial(n) { if (n < 0) throw new Error("Negative values are not allowed"); if (n === 0 || n === 1) return 1; // base case return n * factorial(n - 1); // recursive case } console.log(factorial(5)); // 120 This works because the recursion has a clear stopping point. Here is the kind of pattern that causes stack overflow: function endless(n) { return endless(n + 1); // no base case } ⚠️ Important clarification Infinite recursion is not the only problem. Even valid recursion can fail if the input gets deep enough, because JavaScript engines have limited stack space. That is why for very deep problems, an iterative solution is often safer than recursion. #javascript #webdevelopment #frontend #codinginterview #learninpublic

Understood Hoisting in a much deeper way — not just definition, but what actually happens inside the JavaScript engine 👇 🧸 Imagine JavaScript like a teacher in a classroom Before teaching, the teacher prepares a register (memory) and writes all names first. 👉 JavaScript does the same thing before running code. 🧠 Behind the scenes (Real Concept): JavaScript runs in 2 phases: 1️⃣ Memory Creation Phase 2️⃣ Execution Phase ⚙️ During Memory Creation Phase: JavaScript creates something called an Execution Context (inside the Call Stack) Inside it, memory is allocated: 1- var → stored as undefined 2- let & const → stored but not initialized (Temporal Dead Zone) 3- functions → stored with full definition 💡 Example: console.log(a); var a = 10; 👉 Memory phase: a = undefined 👉 Execution phase: prints undefined 💡 Another example: console.log(b); let b = 20; 👉 Memory phase: b exists but is not initialized 👉 Execution phase: ❌ ReferenceError (because of Temporal Dead Zone) 💡 Functions: sayHi(); function sayHi() { console.log("Hi"); } 👉 Works because functions are fully stored in memory before execution 🎯 So what is Hoisting REALLY? It’s NOT “moving code to the top” ❌ It’s the result of how JavaScript allocates memory inside the Execution Context before execution begins ✅ 💼 Interview Insight: Most people say: 👉 “JS moves variables to top” ❌ Better answer: 👉 “Hoisting is a JavaScript behavior that occurs during the creation phase of the execution context, where memory is allocated for variables and functions before code execution. Variables declared with var are initialized as undefined, while let and const remain uninitialized in the Temporal Dead Zone, and function declarations are stored with their full definition.” #JavaScript #FrontendDeveloper #WebDevelopment #CodingJourney

🚀 **Day 4 – Scope Chain & Lexical Environment in JavaScript** In Day 3, we learned about Execution Context… But now the real question is: 👉 **How does JavaScript find variables when executing code?** 🤔 Let’s understand 👇 --- 💡 **What is Scope?** Scope defines **where a variable can be accessed** 👉 Simple: Scope = where is variable available ? --- 💡 **What is Scope Chain?** When JavaScript tries to access a variable: 👉 It searches in this order: * Current scope * Parent scope * Global scope 👉 This is called **Scope Chain** --- 💡 **Example:** ```js let name = "Aman"; function outer() {  let city = "Indore";  function inner() {   console.log(name);   console.log(city);  }  inner(); } outer(); ``` --- 💡 **Behind the scenes:** When `inner()` runs: * looks for `name` → not in inner * goes to parent → not found * goes to global → found * looks for `city` → found in outer 👉 JavaScript climbs the **scope chain** --- 💡 **What is Lexical Environment?** 👉 It means: Scope is decided by where code is written, not where it is called --- ⚡ **Key Insight** JavaScript uses: * Scope * Scope Chain * Lexical Environment 👉 to resolve variables --- 💡 **Why this matters?** Because this is the base of: * Closures * Variable access * Debugging scope issues --- 👨💻 Continuing my JavaScript fundamentals series 👉 Next: **Hoisting (most misunderstood concept)** 👀 #JavaScript #WebDevelopment #FrontendDevelopment #Coding #SoftwareEngineer #Tech

🧠 JavaScript Array Methods — Complete Cheat Sheet While working with JavaScript daily, I realized one thing… 👉 Strong fundamentals = Faster development + Better code So I created a quick breakdown of the most useful array methods 👇 🔹 Creation Create arrays from different sources → Array.from(), Array.of(), Array.isArray() 🔹 Add / Remove Modify array elements → push(), pop(), shift(), unshift() 🔹 Modify Control structure of arrays → splice() (mutates) → slice() (non-mutating) 🔹 Searching Find values quickly → indexOf(), includes() 🔹 Find ( Important) → find(), findIndex() → findLast(), findLastIndex() 🔹 Transform / Loop → map() → transform data → filter() → select data → reduce() → build single result 🔹 Conditions → some() → at least one true → every() → all true 🔹 Sorting → sort() (mutates) → toSorted() (immutable) 🔹 Flatten / Combine → concat(), flat(), flatMap() 🔹 Modern ( Must Know) → toSpliced(), toReversed(), with() 👉 Immutable operations = cleaner code 🔹 Access → at() (supports negative index 👀) 💡 Key Learning: JavaScript arrays are not just lists — they are powerful tools to write clean, efficient, and scalable code. Understanding when to use: → map vs forEach → filter vs find → mutable vs immutable methods …can completely change your coding style 🚀 📌 Tip: Start using more immutable methods — they help avoid bugs in large applications. Which array method do you use the most? 🤔 #JavaScript #WebDevelopment #FrontendDevelopment #Coding #SoftwareDevelopment

JavaScript in 2026: Temporal API makes dates actually good, Iterator helpers bring lazy evaluation, and RegExp.escape() finally exists after 15 years. Plus: TypeScript v6 is here, Vite dominates the build tool landscape, and 92% of devs are using AI to write code. Wild times. https://lnkd.in/gbNKWc4q #javascript #frontend