Kingston S’ Post

Understanding JavaScript Runtime: From Call Stack to Event Loop (Deep Dive) Most developers use JavaScript daily, but very few truly understand what happens under the hood when code executes. If you want to think like an engineer—not just a coder—you need clarity on the JavaScript runtime model. Let’s break it down. 🔹 JavaScript Engine vs Host Environment JavaScript itself is just a language specification. It does not include things like DOM, timers, or APIs. JavaScript Engine (e.g., V8) Handles: Execution of JS code Memory allocation (Heap) Execution context (Call Stack) Garbage collection Host Environment (Browser / Node.js) Provides: Web APIs (setTimeout, fetch, DOM, events) Event loop Callback queue 👉 Key Insight: JavaScript alone is synchronous. Asynchronous behavior comes from the host environment. 🔹 Memory Model (Heap vs Call Stack) 1. Heap (Memory Allocation) Stores objects, functions, arrays Dynamically allocated Managed by Garbage Collector 2. Call Stack (Execution Context) Executes functions in LIFO (Last In First Out) Each function call creates a stack frame Example: function a() { b(); } function b() { console.log("Hello"); } a(); Call Stack: a() → b() → console.log() 🔹 Web APIs & Async Behavior When you use: setTimeout(() => console.log("Done"), 1000); What actually happens? setTimeout is handed over to Web API Timer runs outside JS engine After 1 second → callback goes to Callback Queue 🔹 Event Loop (The Heart of Async JS) The Event Loop continuously checks: IF (Call Stack is empty) THEN move task from Callback Queue → Call Stack This is why JavaScript can handle async tasks despite being single-threaded. 🔹 Callback Queue Holds tasks like: setTimeout callbacks DOM events (click, load) async operations Example queue: [onClick, onLoad, setTimeout callback] 🔹 Full Flow (Putting It All Together) Code enters Call Stack Async operations move to Web APIs Results go to Callback Queue Event Loop pushes them back to Call Stack when it's empty 🔹 Why This Matters (Real Engineering Insight) Understanding this helps you: Avoid blocking the main thread Debug async bugs (race conditions, delays) Optimize performance (debouncing, throttling) Master promises, async/await, and concurrency patterns 🔹 Final Thought JavaScript is not “asynchronous by nature.” It’s the combination of the JS engine + host environment + event loop that creates the illusion of concurrency. Once you truly understand this model, you stop guessing—and start engineering. If you're serious about becoming a high-level developer, don’t just write code. Understand how it runs. #JavaScript #WebDevelopment #Frontend #Programming #SoftwareEngineering #V8 #EventLoop

POST 1 — The JavaScript Event Loop Is Not What You Think ⚙️ Every JavaScript developer says they understand the event loop. Most of them don't. And that gap is exactly why async bugs are so hard to find and fix. Here's what's actually happening 👇 ───────────────────────── First — JavaScript is single-threaded. Always. One thread. One call stack. One thing running at a time. So how does it handle timers, fetch calls, and user events without freezing? It doesn't. The BROWSER does. And then it reports back. ───────────────────────── The pieces most developers mix up: The Call Stack → where your code actually runs. Functions get pushed in, executed, and popped out. This is the only place code runs. Web APIs → setTimeout, fetch, DOM events. These live OUTSIDE the JS engine — in the browser or Node runtime. They run in separate threads you never manage. The Task Queue (Macrotask Queue) → where callbacks from Web APIs wait to be picked up. setTimeout callbacks land here. The Microtask Queue → where Promise callbacks and queueMicrotask calls wait. This queue has HIGHER priority than the task queue. ───────────────────────── The loop itself: 1. Run everything currently on the call stack until it's empty 2. Drain the ENTIRE microtask queue — every single item, including new ones added during draining 3. Pick ONE task from the task queue 4. Go back to step 1 ───────────────────────── Why this produces bugs nobody expects: Promise.resolve().then() runs before setTimeout(() => {}, 0) — always. Microtasks can starve the task queue if you keep adding new ones during draining. Long synchronous code blocks EVERYTHING — no timers fire, no events respond, no UI updates. ───────────────────────── The practical rule: Never put heavy computation directly on the call stack. Break it up. Use setTimeout to yield back to the event loop. Keep microtask chains short and predictable. ───────────────────────── Did the microtask vs task queue distinction surprise you? Drop a comment below 👇 #JavaScript #WebDevelopment #FrontendDevelopment #Programming #WebPerformance

🚀 JavaScript: The Art of Execution Context & Hoisting (Why it REALLY matters) If you’ve ever wondered why JavaScript behaves the way it does, the answer lies in two core concepts: 👉 Execution Context 👉 Hoisting These aren’t just theory—they define how your code actually runs under the hood. 🧠 1. Execution Context — The Engine Behind Every Line Every time JavaScript runs code, it creates an Execution Context. There are mainly two types: Global Execution Context (GEC) → created when your program starts Function Execution Context (FEC) → created every time a function is invoked 🔄 How it works: Each execution context is created in two phases: 1️⃣ Memory Creation Phase (Hoisting Phase) Variables → stored as undefined Functions → stored with full definition 2️⃣ Code Execution Phase Values are assigned Code runs line by line ⚡ 2. Hoisting — Not Magic, Just Memory Allocation Hoisting is often misunderstood. It doesn’t “move code up”— 👉 it simply means JavaScript allocates memory before execution begins 🔍 Example that explains EVERYTHING console.log(a); // ? console.log(b); // ? console.log(myFunc); // ? var a = 10; let b = 20; function myFunc() { console.log("Hello JS"); } 🧠 Memory Phase: a → undefined b → (in Temporal Dead Zone) myFunc → full function stored 🏃 Execution Phase: console.log(a); // undefined console.log(b); // ❌ ReferenceError console.log(myFunc); // function definition 💣 The TRICKY Part (Arrow Functions vs Normal Functions) console.log(add); const add = () => { return 2 + 3; }; ❓ Output? 👉 ReferenceError: Cannot access 'add' before initialization Why? Because: const variables are hoisted but not initialized They stay in the Temporal Dead Zone (TDZ) So unlike normal functions: console.log(sum); // works function sum() { return 5; } 👉 Function declarations are fully hoisted with definition 👉 But arrow functions behave like variables ❌ 🔥 Key Takeaways ✔ JavaScript creates a new execution context for every function ✔ Memory is allocated before execution starts ✔ var → hoisted as undefined ✔ let / const → hoisted but in TDZ ✔ Function declarations → fully hoisted ✔ Arrow functions → treated like variables 🎯 Why This Matters Understanding this helps you: Debug errors faster ⚡ Write predictable code 🧩 Master interviews 💼 Think like the JavaScript engine 🧠 💡 JavaScript is not weird—you just need to think in terms of execution context. #JavaScript #WebDevelopment #Frontend #Coding #100DaysOfCode #AkshaySaini #Hoisting #ExecutionContext

I used to manipulate objects directly in JavaScript. Until one day, it didn't work. And the errors were almost impossible to trace. Meanwhile JavaScript has built a clean, deliberate API specifically for the job I had been doing messily for a long time. What is Reflect? Reflect is a built-in JavaScript object that provides a set of methods for performing fundamental operations on objects. The same operations you've always done, but in a more controlled, predictable, and reliable way. Reading properties. Setting values. Checking existence. Deleting keys. Reflect does all of this in a clean way. The most important Reflect methods: -> Reflect.get() - reads a property from an object. const user = { name: "Markus" }; Reflect.get(user, "name"); -> "Markus" Same as user.name - but more explicit and safer in dynamic contexts. -> Reflect.set() - sets a property value and returns true or false. const user = { name: "Markus" }; Reflect.set(user, "name", "John"); -> true console.log(user.name); -> "John" Unlike direct assignment - it tells you whether it succeeded by returning true. -> Reflect.has() - checks if a property exists. Reflect.has(user, "name"); -> true Same as the in operator - but cleaner in functional and dynamic code. -> Reflect.deleteProperty() - deletes a property safely. Reflect.deleteProperty(user, "name"); -> true Same as the delete keyword - but returns a boolean instead of throwing silently. -> Reflect.ownKeys() - returns all keys of an object. const user = { name: "Markus", age: 25}; Reflect.ownKeys(user); -> ["name", "age"] Where Reflect truly shines - with Proxy. Reflect and Proxy are natural partners. Inside a Proxy trap, Reflect lets you perform the default operation in a clean way - without rewriting the behaviour from scratch. Example: const proxy = new Proxy(user, { get(target, key) { console.log(`Reading: ${key}`); return Reflect.get(target, key); -> clean default behaviour } }); Reflect doesn't replace what you already know. It refines it. It makes the operations you perform on objects more intentional, consistent, and significantly easier to debug when something goes wrong.

#js #10 **What is Execution Context, Call Stack and Call Back Queue in Javascript** 🧠 1. What is Execution Context? 👉 Execution Context = The environment where JavaScript code runs 📦 Types of Execution Context 1. Global Execution Context (GEC)    Created when program starts    Runs global code    let a = 10;    👉 This runs inside Global Execution Context 2. Function Execution Context (FEC) Whenever a function is called: function greet() { console.log("Hello"); } greet(); 👉 A new execution context is created for greet() 🧩 What’s inside Execution Context? Each context has: Memory (Variables) Code (Execution) 🥞 2. What is Call Stack? 👉 Call Stack = A stack where execution contexts are stored and executed Think of it like plates stacked on top of each other 🔄 How Call Stack Works Example: function one() { two(); } function two() { console.log("Hello"); } one(); Step-by-step: Global Execution Context pushed one() called → pushed two() called → pushed console.log runs two() removed one() removed Stack flow: Call Stack: [ Global ] [ one() ] [ two() ] ← runs Then: [ Global ] 📥 3. What is Callback Queue? 👉 Callback Queue = A queue where async callbacks wait before execution Example: console.log("Start"); setTimeout(() => { console.log("Async"); }, 2000); console.log("End"); Flow: Start → runs setTimeout → goes to browser End → runs After 2 sec → callback goes to Callback Queue 🔄 How everything connects Now combine all three: 👉 Call Stack 👉 Callback Queue 👉 Event system → Event Loop 🔁 Final Flow Call Stack runs normal code Async task completes → goes to queue Event loop checks: If stack empty → move task from queue → stack 🧑🍳 Simple Analogy Execution Context = workspace 🧑💻 Call Stack = stack of tasks 📚 Callback Queue = waiting line 🚶 Event Loop = manager checking when to allow next 🎯 Quick Comparison Concept Meaning Execution Context Environment where code runs Call Stack Where functions execute Callback Queue Where async tasks wait 🧾 Final Summary Execution Context = where code runs Call Stack = manages execution order (LIFO) Callback Queue = stores async callbacks Event Loop connects everything 💡 One-line understanding 👉 JavaScript uses execution contexts inside a call stack, and async tasks wait in a callback queue until the event loop pushes them for execution. #Javascript #ObjectOrientedProgramming #SoftwareDevelopment

#js #19 **Optional Chaining in Javascript** Optional Chaining (?.) in JavaScript is used to safely access nested properties without causing errors if something is null or undefined. 🔹 Why We Need It Without optional chaining: const user = null; console.log(user.name); // ❌ Error: Cannot read property 'name' 👉 This crashes your code. ✅ With Optional Chaining const user = null; console.log(user?.name); // undefined ✅ (no error) 👉 If user is null or undefined, it stops and returns undefined 🔹 Syntax obj?.propertyobj?.[key]obj?.method() ✅ Examples 📌 1. Nested Objects const user = { profile: { name: "Navnath" }}; console.log(user?.profile?.name); // Navnath console.log(user?.address?.city); // undefined 📌 2. Function Calls const user = { greet() { return "Hello"; }}; console.log(user.greet?.()); // Hello console.log(user.sayHi?.()); // undefined (no error) 📌 3. Arrays const arr = [1, 2, 3]; console.log(arr?.[0]); // 1 console.log(arr?.[5]); // undefined 🔥 Real Use Case (Very Common) const response = { data: { user: { name: "Navnath" } }}; const name = response?.data?.user?.name; 👉 Avoids writing multiple checks like: if (response && response.data && response.data.user) ... ⚠️ Important Points ❌ Doesn’t Work on Undeclared Variables console.log(user?.name); // ❌ if user is not defined at all ⚠️ Stops Only on null / undefined const obj = { value: 0 }; console.log(obj?.value); // 0 ✅ (not skipped) 🔥 Combine with Nullish Coalescing (??) const user = {}; const name = user?.name ?? "Guest"; console.log(name); // Guest 🧠 Easy Memory Trick ?. → "If exists, then access" Otherwise → return undefined, don’t crash #Javascript #ObjectOrientedProgramming #SoftwareDevelopment

JSI (JavaScript Interface) — concise overview for React Native What JSI is - JSI is a lightweight C++ layer that exposes a host‑embedded JavaScript runtime (e.g., Hermes, V8, JavaScriptCore) to native code with a stable, low‑overhead API. It replaces the old async JSON‑serialized “bridge” with direct in‑process bindings between JS and native. Why JSI matters - Eliminates expensive serialization/IPC of the legacy bridge. - Enables synchronous, low‑latency calls from JS to native and vice versa. - Serves as the foundation for TurboModules and the Fabric renderer, unlocking better performance and finer control over native interactions. How it works (high level) - JSI exposes a C++ API that represents JS values, functions, objects, and the runtime host. - Native modules and objects can be registered as JSI objects/functions and accessed directly from JS as if they were plain JS objects. - Calls go through the JSI API into the embedded runtime (no automatic JSON stringify/parse), enabling zero-copy or minimal-copy interactions when implemented carefully. - JSI runs in the JS runtime thread context; native code can create bindings that execute synchronously on that thread. Key benefits - Performance: much lower overhead per call vs bridge; reduces CPU and latency for frequent/native-heavy interactions. - Flexibility: native code can expose arbitrary APIs that look/behave like JS objects, enabling richer integrations. - Concurrency & determinism: tighter control over when operations run; easier to integrate with concurrent rendering and Fabric’s commit model. - Better memory semantics: enables zero-copy patterns and improved lifetime management when designed correctly. Common uses in RN New Architecture - TurboModules: lightweight native modules implemented as JSI bindings for faster method calls and direct property access. - Fabric renderer: uses JSI to coordinate view updates and layout with fewer serialized payloads. - Native-hosted JS objects: exposing native data structures or functionality directly into JS space. Debugging & tooling - Use Hermes debugger and Flipper plugins to inspect JS runtime behavior. - Instrument native code and measure round‑trip times to ensure expected gains. - Unit/test JSI modules with engine embeddings where possible. When to adopt - Adopt JSI when you need low‑latency native interactions (animations, gesture handlers, high‑frequency telemetry, tight renderer integrations) or when migrating from the bridge to the New Architecture (Fabric/TurboModules). For simple, infrequent native calls, legacy native modules remain acceptable. Summary JSI is the technical foundation that enables React Native’s New Architecture to reduce bridge overhead and deliver faster, more synchronous-style integrations between JS and native. Properly used, it unlocks substantial performance and UX improvements — but it requires careful threading, memory, and API design. #ReactNative #Perfomance #Optimization

Prototypes & the Prototype Chain If you’re using class in JavaScript, you’re already using prototypes whether you realize it or not. Today was about understanding what that actually means under the hood. What I focused on Prototypes & the chain Every object in JavaScript has an internal link to another object called its prototype. You don’t see it directly, but it’s always there. When you try to access a property, JavaScript follows a simple process: * First, it checks the object itself * If not found, it looks at the object’s prototype * If still not found, it keeps going up the chain * This continues until it either finds the property or reaches null That lookup flow is called the prototype chain. A simple example: ``` function Person(name) {  this.name = name; } Person.prototype.sayHello = function () {  return "Hello " + this.name; }; const user = new Person("Naim"); console.log(user.sayHello()); ``` Here’s what’s happening: * `user` does not have `sayHello` directly * JavaScript looks at `Person.prototype` * It finds `sayHello` there and executes it That’s the prototype chain in action. Manual inheritance (no class) Built inheritance from scratch using constructor functions to understand how objects can share behavior. ``` function Animal(name) {  this.name = name; } Animal.prototype.speak = function () {  return this.name + " makes a sound"; }; function Dog(name) {  this.name = name; } Dog.prototype = Object.create(Animal.prototype); Dog.prototype.constructor = Dog; const d = new Dog("Rex"); console.log(d.speak()); ``` What’s happening here: * `Dog` doesn’t have `speak` * Its prototype is linked to `Animal.prototype` * So JavaScript finds `speak` there through the chain This is the same mechanism behind class-based inheritance. Modifying prototypes A few behaviors stood out while testing: * Adding a method to a prototype affects all existing instances * Property lookup happens at runtime, not when the object is created * If an object defines its own property, it overrides the prototype (shadowing) Example: ``` Person.prototype.age = 25; console.log(user.age); // 25 user.age = 30; console.log(user.age); // 30 (shadows prototype) ``` Takeaway Prototypes are how JavaScript actually shares behavior between objects. The prototype chain is how JavaScript resolves properties. Once this clicks, things like inheritance, method sharing, and even some common bugs start making a lot more sense. #javascript #webdevelopment #frontend #learninginpublic

🚀 TypeScript Best Practices: The Comma (,) vs. The Semicolon (;) Whether you're a seasoned engineer or just starting your TypeScript journey, small syntax choices can make a huge difference in code readability and maintainability. One of the most common questions for developers transitioning from JavaScript is: "When do I use a comma versus a semicolon?" Here is a quick breakdown to keep your enterprise-grade codebase clean and consistent. 🏗️ The Semicolon (;): Defining the Blueprint When you are defining Interfaces or Type Aliases, you are creating a "set of instructions" or a contract for the compiler, not actual data. Best Practice: Use semicolons to terminate members in a structural definition. Why? Interfaces are conceptually similar to class definitions. The semicolon tells the TypeScript compiler that the definition of that specific property or method is complete, acting as a clear boundary for the engine. TypeScript // ✅ Good: Clear separation of structural definitions interface User { id: number; name: string; email: string; } 💎 The Comma (,): Handling the Data When you move from defining a type to creating an Object Literal, you are working with live data in the JavaScript runtime. Best Practice: Use commas to separate key-value pairs in an object. Why? In JavaScript, an object is essentially a list of data. Commas are the standard delimiter for items in a list, just like in an array. Using a semicolon inside an object literal is a syntax error that will break your build! TypeScript // ✅ Good: Standard JavaScript object notation const activeUser: User = { id: 1, name: "John Doe", email: "dev@example.com", // Trailing commas are great for cleaner Git diffs! }; 💡 Senior Dev Tips for Your Workflow Visual Distinction: While TS technically allows commas in interfaces, sticking to semicolons helps you distinguish "Types" from "Objects" at a glance during rapid code reviews. Watch the Typos: Ensure your implementation strictly follows your interface—watch out for common spelling slips like balance vs balence which can lead to runtime headaches. Accessibility First: Remember that clean code is accessible code—maintaining strict typing and clear syntax supports better documentation for everyone on the team. What's your preference? Do you stick to semicolons for types to keep things "classy," or do you prefer the comma-everywhere approach? Let's discuss in the comments! 👇 #TypeScript #WebDevelopment #CodingBestPractices #FrontendEngineering #CleanCode #JavaScript #SeniorDeveloper

𝗧𝗼𝗽𝗶𝗰 𝟭𝟮: 𝗘𝘃𝗲𝗻𝘁 𝗟𝗼𝗼𝗽 (𝗠𝗮𝗰𝗿𝗼 𝘃𝘀 𝗠𝗶𝗰𝗿𝗼𝘁𝗮𝘀𝗸𝘀) JavaScript is single-threaded, yet it handles thousands of concurrent operations without breaking a sweat. The secret isn't raw speed; it's an incredibly strict, ruthless prioritization engine. If you don't understand the difference between a macro and a microtask, your "asynchronous" code is a ticking time bomb for UI freezes. Summary: The Event Loop is the conductor of JavaScript's concurrency model. It continuously monitors the Call Stack and the Task Queues. To manage asynchronous work, it uses two distinct queues with vastly different priorities: Macrotasks (like setTimeout, setInterval, network events) and Microtasks (like Promises and MutationObserver). Crux: The VIP Queue: Microtasks have absolute priority. The engine will not move to the next Macrotask, nor will it allow the browser to re-render the screen, until the entire Microtask queue is completely empty. The Normal Queue: Macrotasks execute one by one. After a single Macrotask finishes, the Event Loop checks the Microtask queue again. The Starvation Risk: Because Microtasks can spawn other Microtasks, a recursive Promise chain can hold the main thread hostage, permanently blocking the UI from updating. The Deep Insight (Architect's Perspective): Traffic Control and Yielding: As architects, we must visualize the Event Loop as a traffic control system where Microtasks are emergency vehicles. When you resolve a massive chain of Promises or heavy async/await logic, you are flooding the intersection with ambulances. The browser's rendering engine—the normal traffic—is forced to sit at a red light until every single emergency vehicle has cleared. We don't just use async patterns for code readability; we must actively manage thread occupancy. For heavy client-side computations, we must intentionally interleave Macrotasks (like setTimeout(..., 0)) to force our code to yield control back to the Event Loop, allowing the browser to paint frames and keeping the UI responsive. Tip: If you have to process a massive dataset on the frontend (e.g., parsing a huge JSON file or formatting thousands of rows), do not use Promise.all on the entire set at once. That floods the Microtask queue and locks the UI. Instead, "chunk" the array and process each chunk using setTimeout or requestAnimationFrame. This gives the Event Loop room to breathe and the browser a chance to render 60 frames per second between your computation chunks. Tags: #SoftwareArchitecture #JavaScript #WebPerformance #EventLoop #FrontendEngineering #CleanCode