Sequential API Calls Kill Performance: Parallelize with Promise.all()

JavaScript's got a thing or two to teach us about variables. It's pretty straightforward, actually - everything's passed by value. But, what's that even mean? It means when you pass a primitive, like a number or a string, JavaScript just makes a copy of it. Simple as that. The original and the copy, they're like two separate entities, living their best lives independently. So, yeah: Primitives are stored right in the variable, no fuss. But objects, on the other hand, are a different story - they're passed by value too, but the value is actually a reference to where the object lives in memory. Think of it like sending someone a map to your house, instead of the actual house. You can make copies of objects, though, using the spread operator or structuredClone() - it's like taking a snapshot of the object, so you can play around with the copy without messing up the original. Here's the lowdown: Primitives are safe, they won't get changed on you. Objects and arrays, though, they share references, so be careful not to mess things up. Just use spread or structuredClone() to make copies, and you're golden. And, honestly, embracing immutability is the way to go - it makes your code predictable, and performant, like a well-oiled machine. Check it out: https://lnkd.in/g-Nj9Rh6 #JavaScript #Variables #Immutability

🟨 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗗𝗮𝘆 𝟰𝟵: 𝗜𝗻𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗼𝗳 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 (𝗖𝗮𝗹𝗹𝗯𝗮𝗰𝗸𝘀 𝗣𝗿𝗼𝗯𝗹𝗲𝗺) In JavaScript, we often use callbacks to handle async tasks — API calls, timers, or events. But callbacks introduce a hidden issue called Inversion of Control. 🔹 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗮 𝗖𝗮𝗹𝗹𝗯𝗮𝗰𝗸? A callback is a function passed to another function and executed later. 𝘴𝘦𝘵𝘛𝘪𝘮𝘦𝘰𝘶𝘵(() => { 𝘤𝘰𝘯𝘴𝘰𝘭𝘦.𝘭𝘰𝘨("𝘑𝘢𝘷𝘢𝘚𝘤𝘳𝘪𝘱𝘵"); }, 1000); 🔹 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗜𝗻𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗼𝗳 𝗖𝗼𝗻𝘁𝗿𝗼𝗹? When we pass a callback, we give control of our code to another function. We don’t control: • When it runs • How many times it runs • Whether it runs at all 🔹 𝗘𝘅𝗮𝗺𝗽𝗹𝗲 𝘢𝘱𝘪.𝘤𝘳𝘦𝘢𝘵𝘦𝘖𝘳𝘥𝘦𝘳(𝘤𝘢𝘳𝘵, 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯 () { 𝘢𝘱𝘪.𝘱𝘳𝘰𝘤𝘦𝘦𝘥𝘛𝘰𝘗𝘢𝘺𝘮𝘦𝘯𝘵(); }); Here: • proceedToPayment is our code • createOrder decides when it runs • Our callback executes only when the API decides, based on its internal logic or async events. This is Inversion of Control in action. 🔹 𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗜𝘀 𝗮 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 • Unexpected behavior • Harder debugging • Leads to callback hell in large apps 🔹 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻 Promises and async / await keep control in our hands. 🔹 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆 Callbacks give control away. Promises bring it back. 💬 GitHub link in the comments for examples #JavaScript #Day49 #100DaysOfCode #Frontend

Day 2: How JavaScript actually runs! (Execution Context Explained) 🚀 Yesterday, we covered the basics. Today, let’s look under the hood. If you’ve ever wondered why your code behaves a certain way, the answer lies in the Execution Context. Think of JavaScript as a two-step process. It doesn't just "run" code; it prepares first. 1. Phase 1: Memory Creation (The Setup) Before executing a single line, JS scans your code. It "skips" the values and just allocates space. Variables are set to undefined. Functions are stored entirely. This is why you can call a function before it's even defined! (Hoisting). 2. Phase 2: Code Execution (The Action) ⚡ Now, JS runs the code line-by-line. It fills those empty memory slots with real values and executes functions. 🖼️ Let’s break down the image example: Look at the code in the attached image: Memory Phase: x and y are born as undefined. The double function is saved. Execution Phase: x becomes 10. The Call Stack: When double(10) is called, a new "mini-context" is pushed to the top of the stack. It calculates 10 * 2, returns 20, and then pops off the stack to keep things clean. The Key Rule: JS is Single-Threaded. It can only do one thing at a time. The Call Stack ensures it never gets confused about what to do next. Understanding this is the "bridge" between being a beginner and a pro. Once you get the Execution Context . #JavaScript #WebDevelopment #100DaysOfCode #ProgrammingTips #SoftwareEngineering #CodingJourney #BeginnerCoder

🚀 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗮𝘀𝘆𝗻𝗰/𝗮𝘄𝗮𝗶𝘁: 𝘄𝗵𝘆 𝗶𝘁 𝗹𝗼𝗼𝗸𝘀 𝘀𝘆𝗻𝗰𝗵𝗿𝗼𝗻𝗼𝘂𝘀 𝗯𝘂𝘁 𝗶𝘀𝗻’𝘁 JavaScript doesn’t execute async/await synchronously; it only makes asynchronous code easier to read. Example: console.log("A"); async function test() {  console.log("B");  await Promise.resolve("C");  console.log("D"); } test(); console.log("E"); Output:  A B E D What actually happens: 1) Global execution starts "A" is printed 2) test() is called "B" is printed 3) await Promise.resolve("C") • The promise is already resolved, but await still pauses, 𝗮𝘄𝗮𝗶𝘁 𝗻𝗲𝘃𝗲𝗿 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗲𝘀 𝗶𝗺𝗺𝗲𝗱𝗶𝗮𝘁𝗲𝗹𝘆 • Suspends test execution and lets the rest of the code run first • The remaining code (console.log("D")) is scheduled as a microtask 4) Global code continues "E" is printed 5) Microtask queue runs async function resumes from where it paused "D" is printed See? Nothing got blocked. That’s JavaScript for you, and async/await just keeps async code readable. Thanks to Akshay Saini 🚀 for explaining this concept in Namaste Javascript, which made async/await click for me! 👏👏 #JavaScript #AsyncAwait #EventLoop #FrontendDevelopment #WebDevelopment

𝗵𝗼𝘄 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗵𝗮𝗻𝗱𝗹𝗲𝘀 𝗮𝘀𝘆𝗻𝗰 𝗰𝗼𝗱𝗲? It's single-threaded. So how does it handle setTimeout, API calls, and user clicks without freezing? 𝗧𝗵𝗲 𝗮𝗻𝘀𝘄𝗲𝗿: Event Loop Here's what actually happens: JavaScript has 4 main parts: ↳ Call Stack — runs your code ↳ Web APIs — handles async tasks (setTimeout, fetch, DOM events) ↳ Callback Queue — stores completed callbacks ↳ Event Loop — moves callbacks to stack when stack is empty Example: console.log("Start"); setTimeout(() => {  console.log("Timeout"); }, 0); console.log("End"); Output:  Start  End  Timeout Wait, why does Timeout come last? ↳ console.log("Start") → runs immediately ↳ setTimeout → sent to Web API ↳ console.log("End") → runs immediately ↳ Stack empty → Event Loop pushes callback ↳ console.log("Timeout") → runs now Even with 0ms delay, setTimeout waits for stack to clear. My takeaway: JavaScript isn't slow. It's just smarter than I thought. Understanding Event Loop = understanding async JavaScript. #JavaScript #FrontendDevelopment #LearningInPublic #SDE

🟨 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗗𝗮𝘆 𝟰𝟴: 𝗔𝘀𝘆𝗻𝗰 & 𝗔𝘄𝗮𝗶𝘁 (𝗗𝗲𝗲𝗽 𝗯𝘂𝘁 𝗦𝗶𝗺𝗽𝗹𝗲) Some JavaScript operations take time — and async & await help us handle them cleanly. 🔹 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗮𝘀𝘆𝗻𝗰? • async is a keyword used to create an async function • An async function always returns a Promise • Even a normal return value is wrapped inside a Promise async function getData() { return "JavaScript"; } 🔹 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗮𝘄𝗮𝗶𝘁? • await can only be used inside an async function • It pauses the execution of that function only • JavaScript continues running other code const result = await fetch("/api"); 🔹 𝗛𝗼𝘄 𝗔𝘀𝘆𝗻𝗰/𝗔𝘄𝗮𝗶𝘁 𝗪𝗼𝗿𝗸𝘀 • Code runs normally until it hits await • Function execution is suspended • Once the Promise resolves, execution continues from the same line 🔹 𝗪𝗵𝘆 𝗪𝗲 𝗨𝘀𝗲 𝗔𝘀𝘆𝗻𝗰/𝗔𝘄𝗮𝗶𝘁 • Makes async code look synchronous • Improves readability • Easier error handling with try / catch 🔹 𝗞𝗲𝘆 𝗣𝗼𝗶𝗻𝘁 Async & await do not block JavaScript They only pause the async function — not the event loop. 💬 GitHub link in the comments for examples #JavaScript #Day48 #100DaysOfCode #Frontend

🚀 Day 3 Not Just Motivation — Real Concepts to Build Strong Technical Understanding (Part 3) JavaScript Concept That Finally Made Everything Clear: Global Execution Context (GEC) Most JavaScript confusion doesn’t come from complex syntax. It comes from not knowing how JavaScript starts executing your code. Before the first line runs, JavaScript does something very important. 👇 It creates the Global Execution Context (GEC). What really happens when a JS file runs? 🔹 Step 1: GEC is created This is the default execution environment for your program. 🔹 Step 2: GEC is pushed into the Call Stack Yes — the Call Stack starts with GEC. And since the Call Stack follows LIFO (Last In, First Out): GEC stays at the bottom until everything finishes. No function can execute unless GEC already exists. GEC works in two phases (this is key) 1️⃣ Memory Creation Phase (Preparation) Memory is allocated before execution var → undefined Functions → full definition stored let / const → exist but uninitialized (TDZ) 👉 This explains hoisting without any mystery. 2️⃣ Execution Phase Code runs line by line Variables get actual values Functions create their own execution contexts Each new context goes on top of the Call Stack And when a function finishes? 👉 Its execution context is popped off the stack (LIFO in action). One subtle but important detail In the global execution context: Browser → this === window Node.js → this === global Why this concept matters Once you truly understand GEC: Hoisting stops being confusing Call Stack behavior makes sense Async concepts feel more logical Debugging becomes easier 📌 Key takeaway JavaScript doesn’t jump into execution. It prepares memory, sets context, pushes GEC to the Call Stack — then starts running your code. If JavaScript ever felt unpredictable, it’s not chaos. It’s a well-defined execution model — once you see it, you can’t unsee it. #JavaScript #ExecutionContext #CallStack #React #Frontend #TechConcepts #LearningInPublic

💡 Hoisting happens before code execution. ❓ Why are function declarations hoisted but arrow functions are not? In JavaScript, hoisting means the JS engine moves declarations to the top of the file before running the code. ✅ Function declarations are fully hoisted. That means both the function name and its body are stored in memory during the creation phase. So you can call a function declaration even before writing it in the code. ❌ Arrow functions are not hoisted the same way because they are treated like variables. If an arrow function is assigned to const or let, only the variable name is hoisted—not its value. Until the code reaches that line, the arrow function doesn’t exist yet. 👉 So if you try to call an arrow function before it’s defined, JavaScript throws an error. #engineer #webdevelopment #javascript #mernstackdeveloper #fullstackdeveloper #learnwithisnaan

Ever wondered how JavaScript handles asynchronous code while being single-threaded? Here’s a visual breakdown using setTimeout() 👇 🔄 Execution Flow Explained 1️⃣ Global Execution (Main Function) When the program starts, the main function (global execution context) is pushed into the Call Stack. All synchronous code runs first. 2️⃣ Encountering an Async Function When JavaScript encounters an asynchronous function like setTimeout, it: Pushes it into the Call Stack Immediately removes (pops) it after registering the task 3️⃣ Web API Takes Control The async task is handed over to the Web API, where: The timer starts running (e.g., 4 seconds) JavaScript does NOT wait — it continues executing other code 4️⃣ Callback Queue Once the timer completes: The callback function (console.log("Hello World")) is pushed into the Callback Queue 5️⃣ Event Loop in Action The Event Loop continuously checks: Is the Call Stack empty? 6️⃣ Execution When the Call Stack becomes empty: The Event Loop moves the callback from the Callback Queue to the Call Stack The callback executes and prints the output 🎉 JavaScript is single-threaded, but thanks to: Web APIs Callback Queue Event Loop …it can handle non-blocking asynchronous operations efficiently. If you have any doubts or want to discuss this further, feel free to connect with me or drop a comment. Happy to help! Apoorv M. #JavaScript #EventLoop #WebAPI #AsynchronousJavaScript #Frontend #WebDevelopment #Programming #LearnJavaScript