Understanding JavaScript Promises: A Foundation for Modern Development

A small JavaScript confusion that every developer faces: In the browser we use window. In Node.js we use global. So what do we use when writing environment-agnostic code? JavaScript solved this with globalThis. One global object. Works everywhere. I wrote a quick blog explaining: • global vs window • Why globalThis was introduced • Why var attaches to it but let doesn't Full blog 👇 https://lnkd.in/gme-Gtdr Hitesh Choudhary Piyush Garg Akash Kadlag #chaicode #javascript #javascript_framework #cohort2026

JavaScript's New Explicit Resource Management Proposal The article explains a new JavaScript proposal that introduces standardized ways to clean up resources and manage memory, making it easier for developers to ensure their code properly disposes of objects when they're no longer needed. - Implicit resource management already exists through WeakSet and WeakMap, which hold "weak" references that don't prevent garbage collection - Explicit resource management introduces a standardized `[Symbol.dispose]()` method to replace inconsistent cleanup methods like `close()`, `abort()`, and `disconnect()` - The `using` keyword is a new variable declaration (first since 2015) that automatically calls `[Symbol.dispose]()` when a variable goes out of scope - Variables declared with `using` are block-scoped like `const` and cannot be reassigned - The proposal has reached stage three of the standards process and is already implemented in most major browsers except Safari - Developers can create custom disposers in their classes to define cleanup behavior when instances go out of scope This proposal provides a predictable, declarative approach to resource cleanup that reduces the risk of leaving connections open or resources locked, preventing memory leaks and ensuring JavaScript applications clean up after themselves automatically. https://lnkd.in/gY_25GYt #javascript #frontend #cleanup #garbagecollection #resourcemanagement

You write a variable… but JavaScript says it doesn’t exist. How? When JavaScript enters a new scope, it scans for all variable declarations before running any code. Variables declared with let and const are acknowledged, but intentionally kept off-limits until their declaration line is reached. In JavaScript, variables declared with let and const are hoisted, but they cannot be used before their declaration line runs. The period between the start of the scope and the actual declaration is called the Temporal Dead Zone (TDZ). During this time: The variable technically exists in memory But JavaScript blocks any access to it Example: console.log(user); -> ReferenceError let user = "Daniel"; Even though user is hoisted, accessing it before the declaration throws an error because it’s still inside the TDZ(Temporal Dead zone). var had no TDZ - and that freedom quietly caused bugs that were notoriously hard to trace. let and const were introduced with TDZ deliberately, to enforce order, intention, and predictability in your code. With let and const, timing matters. The simple rule that keeps you safe: Always declare your variables before you use them. Every time. No exceptions. The TDZ was designed to prevent unpredictable bugs and force cleaner, more intentional code. It’s one of the subtle ways modern JavaScript improves reliability.

Promises in JavaScript is actually an interesting concept. Promises are one of the most important concepts in modern JavaScript. A Promise is an object that represents a value that will be either available now, later or never. It has three states: pending, fulfilled and rejected. Instead of blocking the program while waiting for something like data or an image to load, a promise allows JavaScript to continue running and then react when the task finishes. We can build a promise by using the Promise constructor, which takes an executor function with two parameters: resolve and reject. Resolve is called when the operation succeeds, and reject is called when something goes wrong. We can also consume promises using the .then() to handle success and catch() to handle errors. Each .then() method returns a new promise which allows us to chain asynchronous steps in sequence. Another powerful concept is PROMISIFYING, this simply means converting old callback-based APIs (like setTimeout or certain browser APIs) into promises so they can fit into modern asynchronous workflows. Understanding how to build, chain and handle promises properly is the foundation we need in mastering asynchronous JavaScript. #JavaScript #WebDevelopment #FrontendDevelopment #TechJourney #Growth

If JavaScript Promises ever felt confusing, it’s not your fault. They’re usually explained incorrectly. I wrote a 3-part, story-driven guide that covers: • Promises • chaining • async/await Link ↓ https://lnkd.in/gUwTZHUr

Is JavaScript truly isomorphic? If your module imports `node:fs`, it has already chosen its platform. Here’s my take on moving platform decisions to the composition root using standard DI. #JavaScript #SoftwareArchitecture #NodeJS #DependencyInjection #WebDevelopment

Difference Between null and undefined in JavaScript A developer once told me, “My code is broken and I don’t know why.” We looked at it together, and the bug came down to one tiny detail: null vs undefined. Two words that look harmless. Two values that both seem to mean “nothing.” Yet that small misunderstanding caused hours of confusion. This happens more often than people admit. JavaScript is friendly, but it has weird behavior sometimes. And some of the biggest bugs come from the smallest concepts we rush past while learning. Understanding the difference between null and undefined is one of those quiet fundamentals that saves you from future headaches. undefined means a variable has been declared, but no value has been assigned yet. JavaScript assigns undefined by default. JavaScript let aniekan; console.log(aniekan); - undefined null on the other hand  is an intentional value. It means the developer has explicitly set the variable to have no value. JavaScript let aniekan = null; Key differences undefined → value is missing or not yet assigned null → value is intentionally empty A common surprise: typeof null; - returns an"object" This is a well-known JavaScript weird behavior. Even though null is not an object, but typeof null returns "object". The difference between null and undefined is small, but it changes how you think about intention in your code. One is accidental. The other is deliberate. Knowing when to use each makes your programs easier to read and easier to trust. If this helped clarify things, give it a like so more developers can learn from it. Repost it for someone new to JavaScript. And drop your thoughts in the comments; when did null or undefined first confuse you? Let’s talk about it.

𝗧𝗵𝗲 𝗔𝘀𝘆𝗻𝗰𝗵𝗿𝗼𝗻𝗼𝘂𝘀 𝗡𝗮𝘁𝘂𝗿𝗲 𝗼𝗳 𝗝𝗮 v𝗮𝗦𝗰𝗿𝗶𝗽𝘁 When you start writing JavaScript, it seems simple. Code runs from top to bottom, line by line. But then you learn about timers like setTimeout and setInterval. Things get weird. You find out JavaScript is single-threaded. It can only do one thing at a time. Think of a fast-food restaurant with one cashier. This cashier is like the Call Stack. It does things one by one. If a function takes too long, like fetching data from an API, it won't freeze the whole app. But how does it work? JavaScript uses Web APIs, the Callback Queue, and the Event Loop. Web APIs handle long tasks like network calls. The Callback Queue holds the results. The Event Loop checks the Call Stack and runs the next task. There are two kinds of Callback Queues: Macro Task Queue for timers and Micro Task Queue for promises. Over time, async code in JavaScript evolved. We used Callback Functions, then Promises, and now Async/Await. Async/Await makes async code look sync. You declare a function with async and use await to pause it. This makes it non-blocking. JavaScript is single-threaded, but the Event Loop and environment give it superpowers. The Call Stack runs sync code, and the Event Loop checks for empty stacks to push queue tasks. Source: https://lnkd.in/gERccB3C

𝐇𝐨𝐰 𝐑𝐞𝐚𝐜𝐭 𝐰𝐨𝐫𝐤𝐬 𝐮𝐧𝐝𝐞𝐫 𝐭𝐡𝐞 𝐡𝐨𝐨𝐝. You write JSX. The browser has no idea what JSX is. So how does your React code run? 🔵 𝐒𝐭𝐞𝐩 𝟏: 𝐂𝐨𝐦𝐩𝐢𝐥𝐚𝐭𝐢𝐨𝐧 JSX is not JavaScript. Before your code ever reaches the browser, a tool like Babel transforms it. This: <𝘉𝘶𝘵𝘵𝘰𝘯 𝘰𝘯𝘊𝘭𝘪𝘤𝘬={𝘩𝘢𝘯𝘥𝘭𝘦𝘊𝘭𝘪𝘤𝘬}>𝘚𝘶𝘣𝘮𝘪𝘵</𝘉𝘶𝘵𝘵𝘰𝘯> Becomes this: 𝘙𝘦𝘢𝘤𝘵.𝘤𝘳𝘦𝘢𝘵𝘦𝘌𝘭𝘦𝘮𝘦𝘯𝘵(𝘉𝘶𝘵𝘵𝘰𝘯, { 𝘰𝘯𝘊𝘭𝘪𝘤𝘬: 𝘩𝘢𝘯𝘥𝘭𝘦𝘊𝘭𝘪𝘤𝘬 }, "𝘚𝘶𝘣𝘮𝘪𝘵") We can say JSX is just a cleaner way to write createElement calls. 🟣 𝐒𝐭𝐞𝐩 𝟐: 𝐓𝐡𝐞 𝐕𝐢𝐫𝐭𝐮𝐚𝐥 𝐃𝐎𝐌 When your component renders, React doesn't touch the real DOM immediately. Instead, it builds a lightweight JavaScript object, a tree that describes what the UI should look like. This tree is the Virtual DOM. 🟢 𝐒𝐭𝐞𝐩 𝟑: 𝐑𝐞𝐜𝐨𝐧𝐜𝐢𝐥𝐢𝐚𝐭𝐢𝐨𝐧 When state changes: ➡️ React builds a new Virtual DOM tree ➡️ Compares it to the previous one (diffing) ➡️ Calculates the minimum set of changes needed ➡️ Applies only those changes to the real DOM (commit phase) This is why you can call setState multiple times and React doesn't update the DOM after each one, but it batches the changes and commits once. 🔑 The real DOM is expensive to update. Not because it's slow, but because every change can trigger style recalculations, layout, and repaint. React's job is to minimize how often that happens. Good code habits are built on top of strong fundamentals. A lot of developers get really good at the "what" without understanding the "why." Knowing how the tools you use every day work can really help making good decisions.