Understanding JavaScript Objects in Heap Memory

Deep Dive into Strings & Date Today I explored some very important core concepts of JavaScript — Strings and Date objects. Here’s what I learned: 🔹 String Basics Different ways to create strings ("", '', template literals `${}`) String immutability (operations return new strings) length property 🔹 String Methods .toUpperCase() / .toLowerCase() .trim() for cleaning whitespace .split() to convert string → array .replace() & .replaceAll() .slice() and .substring() for extracting parts .indexOf(), .lastIndexOf(), .includes() for searching Understanding that strings are immutable really changed how I think about string manipulation. ⏳ JavaScript Date & Time Then I went deeper into how JavaScript handles time: new Date() .toString() vs .toLocaleString() .getDay(), .getDate(), .getMonth() (0-based indexing ⚠️) Date.now() → milliseconds since 1 Jan 1970 (Unix Epoch) But the most interesting part 👇 💡 How JavaScript Gets Time JavaScript doesn’t generate time itself. It takes time from the Operating System, which gets it from: 🧠 Real-Time Clock (RTC) on the motherboard 🔋 CMOS battery (keeps time even when system is off) ⚡ CPU Clock (high-speed internal counter) Understanding the difference between: Physical CPU Clock Real-Time Clock OS System Clock …gave me clarity on how time actually works inside a computer. The more I learn JavaScript internals, the more I realize how deeply connected software is with hardware. Consistency > Motivation 💪 Still learning. Still building. #JavaScript #WebDevelopment #JSInternals #LearningInPublic #100DaysOfCode #DSA #Frontend CoderArmy

Ever wondered what actually happens behind the scenes when JavaScript runs your code? 🤔 How Variables & Functions Work Behind the Scenes in JavaScript Today I focused on understanding what actually happens inside the JavaScript engine when we write variables and functions — and it completely changed how I read JS code. 🧠 Step 1: JavaScript Creates an Execution Context Before executing any code, JavaScript creates an Execution Context. This happens in two phases: 1. Creation Phase (Memory Allocation Phase) In this phase, JavaScript scans the entire code before running it and prepares memory. ✔ Variables var variables are allocated memory and initialized with undefined let and const are also allocated memory, but they stay in the Temporal Dead Zone (TDZ) until initialized ✔ Functions Function declarations are stored fully in memory (function body included) Function expressions & arrow functions behave like variables and depend on var / let / const 👉 This is the real reason hoisting exists. 2.Execution Phase (Code Runs Line by Line) Now JavaScript starts executing the code: Variables get their actual values Functions are executed when they are called A new Function Execution Context is created for every function call Each context is pushed to the Call Stack After execution, it is removed from the stack Why Functions Can Be Called Before Declaration? because function declarations are fully hoisted during the creation phase. 💡 Key Takeaways JavaScript doesn’t execute code directly — it prepares first Hoisting is a byproduct of the creation phase var, let, and const differ because of how memory is allocated Understanding execution context makes debugging much easier. Mastering the basics is what truly levels up a developer. Thanks to Anshu Pandey and Sheryians Coding School #JavaScript #JavaScriptbasics #ES6 #JSEngine #coding

💡 Understanding the JavaScript Event Loop (Made Simple) When I started learning JavaScript, I was confused about how setTimeout, button clicks, and API calls worked — especially since JavaScript is single-threaded. This visual really helped me understand what happens behind the scenes: 👉 1. Call Stack – Runs code line by line (synchronous code) 👉 2. Web APIs – Handles async tasks like timers and fetch requests 👉 3. Callback Queue – Stores completed async callbacks 👉 4. Event Loop – Moves callbacks to the stack when it’s empty 🔎 Simple Example: console.log("Start"); setTimeout(() => { console.log("Inside Timeout"); }, 0); console.log("End"); 👉 What do you think the output will be? The output is: Start End Inside Timeout Even though the timeout is set to 0 milliseconds, it doesn’t run immediately. Here’s why: 1️⃣ "Start" goes to the call stack → executes 2️⃣ setTimeout moves to Web APIs 3️⃣ "End" executes 4️⃣ The callback moves to the queue 5️⃣ The Event Loop waits until the stack is empty 6️⃣ Then it pushes "Inside Timeout" to the stack That’s the Event Loop in action 🚀 Understanding this concept made: ✅ Promises easier ✅ Async/Await clearer ✅ Debugging smoother If you're learning JavaScript, mastering the Event Loop is a big step forward. #JavaScript #WebDevelopment #BeginnerDeveloper #AsyncProgramming #FrontendDevelopment #mernstack #fullstack

I’ve lost count of how many times I’ve seen the same explanation: “Primitives are passed by value, objects by reference.” It’s everywhere—in tutorials, interviews, Stack Overflow answers… and honestly, it’s been driving me nuts because it’s not quite accurate in JavaScript. So I finally sat down and wrote the post I wish I’d read years ago: “Primitives vs Objects: How JavaScript Values Actually Work” The real difference isn’t “value vs reference”—it’s mutability. Primitives are immutable (you can’t change them, only replace them). Objects are mutable (you can change their contents, and everyone with a reference sees it). Everything else flows from there: why a = b behaves differently, why {} === {} is false, why mutating an object affects the “original”, why reassignment doesn’t, and even why JavaScript technically uses “call by sharing” for everything. If you’ve ever been confused by why changing an array in a function changes the original, or why strings act “weird” compared to objects—this might clear things up. Check it out here: https://lnkd.in/dvRfbPFC What’s the biggest JavaScript primitive/object misconception you’ve had to unlearn? Drop it below—I’m curious. 👇 #JavaScript #WebDevelopment #Programming #Frontend

🥇Mastering JavaScript — One Concept at a Time (1/32) What are Variables & why var, let, const really matter. As part of my journey to master JavaScript, I decided to revisit the very basics starting with variables. And honestly, understanding this properly explains so many mistakes I made earlier. 📦What are variables? Variables are like containers that store data. They help us store, reuse, and update information from simple numbers to complex objects and arrays. Think of a variable as a box with a name on it: -The name is the variable identifier -The value is whatever data we put inside In JavaScript, we create these boxes using: 👉 var, let, and const 🧓 var — Old and risky 1️⃣Function scoped (not block scoped) 2️⃣Can be redeclared and reassigned 3️⃣Hoisted and initialised with undefined 🧑💻 let — Modern and safer 1️⃣Block scoped { } 2️⃣Can be reassigned, but not redeclared 3️⃣Hoisted, but stays in the Temporal Dead Zone (TDZ) 🔐 const — Predictable by default 1️⃣Must be assigned at declaration 2️⃣Cannot be reassigned or redeclared 3️⃣Block scoped 4️⃣Also affected by TDZ 🧠 Mindset Revisiting fundamentals is not about “going backwards”, it’s about building stronger foundations. My current approach: - Prefer const by default - Use let only when reassignment is necessary - Avoid var in modern JavaScript - Understanding why these rules exist makes the language feel far more predictable and reliable. 📌 Note: I intentionally didn’t go deep into HOISTING and the TDZ, I will break those down clearly in the next post in this series. This is just the beginning of my journey to master JavaScript — one concept at a time. 💬 How did you first understand the difference between var, let, and const? #JavaScript #LearningInPublic #WebDevelopment #FrontendDevelopment

✨ 𝗗𝗮𝘆 𝟴 𝗼𝗳 𝗠𝘆 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗝𝗼𝘂𝗿𝗻𝗲𝘆 🚀 Today I explored 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗢𝗯𝗷𝗲𝗰𝘁𝘀 𝗮𝗻𝗱 𝘁𝗵𝗲𝗶𝗿 𝗠𝗲𝗺𝗼𝗿𝘆 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗶𝗻-𝗱𝗲𝗽𝘁𝗵, and learned how objects are actually structured behind the scenes in memory. I discovered that JavaScript objects are stored in the heap, and the variable holds a reference (pointer) in the stack. But what’s more interesting is that internally, objects have different pointers:   • 𝗠𝗮𝗽 𝗣𝗼𝗶𝗻𝘁𝗲𝗿 → points to the object’s hidden class (structure and layout of properties)   • 𝗣𝗿𝗼𝗽𝗲𝗿𝘁𝗶𝗲𝘀 𝗣𝗼𝗶𝗻𝘁𝗲𝗿 → points to where named properties are stored   • 𝗘𝗹𝗲𝗺𝗲𝗻𝘁𝘀 𝗣𝗼𝗶𝗻𝘁𝗲𝗿 → points to indexed elements (used especially in arrays) This explains how JavaScript engines optimize objects for performance and access speed. Understanding these low-level details helps me see JavaScript beyond syntax — it’s helping me understand how things really work under the hood. Building strong fundamentals step by step. #JavaScript #100DaysOfCode #WebDevelopment #LearningJourney #FrontendDevelopment #ComputerScience

Stop Mutating Your State! 🛑 Understanding Deep Copy vs. Shallow Copy in JavaScript As JavaScript developers, we often run into "ghost bugs" where updating one object accidentally changes another. This happens because of how JavaScript handles References. The Pitfall: Shallow Copying Using the spread operator (...) is great for simple, flat objects, but it only performs a "shallow" copy. If your object contains nested objects or arrays, the references to those nested items are still shared between the original and the copy. The Solution: Modern Deep Copy In the past, we relied on JSON.parse(JSON.stringify(obj)) which is slow and fragile or external libraries like Lodash. Today, we have a superior, built-in solution: structuredClone(). Why should you switch to structuredClone()? Predictable State: Essential for frameworks like React where immutability is key. Clean Code: No more "Spread Hell" where you manually spread five nested levels just to update one property. Performance: It is a native browser API, highly optimized, and handles complex data types natively. (See the code snippet below for the direct comparison!) How are you handling complex state updates in your projects? Are you still using the spread operator for everything, or have you fully adopted structuredClone? Let’s discuss in the comments! 🚀 #JavaScript #WebDevelopment #ReactJS #CleanCode #FullStack #SoftwareEngineering #ProgrammingTips #webdevelopment #programming #TechFuture

🚀 JavaScript Journey Started | Strong Basics First 🚀 I’ve started my JavaScript journey with one clear goal: master the fundamentals before jumping into advanced stuff. Right now, I’ve built a JavaScript Strings practice repository, fully documented in README.md, focusing on clarity, clean code, and real understanding 📘 What this repo covers: • JavaScript Strings basics & immutability • Indexing & character access • New lines (\n) & escaping strings • Template literals & string interpolation • ASCII / char codes • Core string methods: indexOf, includes, slice, replace, replaceAll, toUpperCase, toLowerCase, repeat, trim • Basic user input using prompt() Simple goal: understand → practice → document. Alongside JavaScript, I’m also working on CSS projects to improve layouts, structure, and UI skills 🎨 At the same time, I’ve started DSA (Arrays) and solved problems like array traversal, min & max elements, linear search, reversing arrays, pass by reference, and sum/product logic 🧠 GitHub Repository (JavaScript Strings Practice): https://lnkd.in/dyPNNcsi This is just the beginning. Staying consistent, learning daily, and building step by step 💪 #JavaScript #JSBasics #JSStrings #WebDevelopment #CSSProjects #DSA #Arrays #LearnInPublic #100DaysOfCode #CodingJourney

One of the most fundamental — yet most misunderstood — areas of JavaScript. If you don’t fully understand how functions behave under the hood, hoisting, closures, async patterns, and even React logic will feel confusing. In this post, I’ve broken down JavaScript functions from an execution-model perspective — not just syntax, but how the engine actually treats them during memory creation and runtime. Covered in this slide set: 1. Difference between Function Declarations and Function Expressions 2. How hoisting really works (definition vs undefined memory allocation) 3. Anonymous Functions and where they are actually valid 4. Named Function Expressions and their internal scope behavior 5. Parameters vs Arguments (including arity behavior in JS) 6. First-Class Functions and why functions are treated like values 7. Arrow Functions and lexical this binding Clear explanation of: 1. Why function declarations are hoisted with definition 2. Why function expressions throw “not a function” errors before assignment 3. Why anonymous functions can’t stand alone 4. How internal names in Named Function Expressions work 5. How JavaScript allows flexible argument passing 6. Why arrow functions don’t have their own this or arguments These notes are written with: 1. Interview mindset 2. Execution context clarity 3. Production-level understanding 4. Engine-level reasoning If you truly understand this topic, you automatically improve your understanding of: 1. Closures 2. Higher-Order Functions 3. Async JavaScript 4. React Hooks 5. Node.js middleware 6. Functional programming patterns Part of my JavaScript Deep Dive series — focused on building strong fundamentals, execution clarity, and real engineering-level JavaScript understanding. #JavaScript #JavaScriptFunctions #Hoisting #Closures #FirstClassFunctions #ArrowFunctions #ExecutionContext #FrontendDevelopment #BackendDevelopment #WebDevelopment #MERNStack #NextJS #NestJS #SoftwareEngineering #JavaScriptInterview #DeveloperCommunity #LearnJavaScript #alihassandevnext