Native JavaScript Set Methods Boost Performance

Day 14: Async / Await in JavaScript Promises improved async code… But Async/Await made it beautiful. ✨ Async/Await lets us write asynchronous code that looks like synchronous code. 🔹 What is async? When you add async before a function: 👉 It automatically returns a Promise async function greet() { return "Hello"; } greet().then(res => console.log(res)); Even though we return a string, JavaScript wraps it inside a Promise. 🔹 What is await? await pauses execution until the Promise resolves. async function fetchData() { const data = await fetch("/api/data"); console.log(data); } 👉 await can only be used inside an async function. 🔹 Error Handling with try/catch async function getData() { try { const res = await fetch("/api/data"); const data = await res.json(); console.log(data); } catch (error) { console.log("Error:", error); } } Much cleaner than multiple .then().catch() chains. 🔥 Why Async/Await is Better? ✅ Cleaner & more readable ✅ Avoids Promise chaining complexity ✅ Easier error handling ✅ Looks synchronous but runs asynchronously #Remeber :Important Interview Point Even with await, JavaScript is still single-threaded. Async/Await works because of: ✔️ Promises ✔️ Event Loop ✔️ Microtask Queue #JavaScript #AsyncAwait #Promises #webdevelopment #LearnInPublic

Did you know that when you use an array inside a JavaScript template literal, it doesn’t behave like an array at all? If you write something like: `Stack: ${['React', 'Node', 'TypeScript']}` you might expect JSON-style output or the array structure. But JavaScript actually produces: "Stack: React,Node,TypeScript" That’s because template literal interpolation triggers implicit coercion: .toString() → .join(',') This isn’t a quirk — it’s part of the language design, and arrays have always been stringified using commas. Where this is useful There are a few scenarios where this implicit join is convenient: 1 - quick logging or debugging 2 - passing arrays into string-based utilities 3 - small helper functions where formatting doesn’t matter, etc. Where it becomes risky In more sensitive areas — UI text, error messages, URLs, file paths, nested arrays — this implicit join can lead to subtle formatting bugs or unreadable output, especially if you didn’t intend commas. My recommendation For clarity and predictability in production code, being explicit is usually the better choice: `Technologies: ${tech.join(', ')}` Making the formatting intentional helps avoid surprises and keeps code easier to understand for everyone reading it. #JavaScript #React #WebDevelopment #FrontendEngineering

Stop misusing JavaScript array methods. Small choices like this quietly shape code quality. One of the most common clean-code mistakes I see is using `forEach()` when the real intention is transformation. If your goal is to create a new array from existing data, `map()` is the right tool. `map()` returns a new array. It keeps your logic functional and predictable. It communicates intent clearly: “I am transforming data.” That clarity improves readability and long-term maintainability. `forEach()`, on the other hand, is built for side effects—logging, DOM updates, triggering external behavior. It does not return a new array. When you push into another array inside `forEach()`, you’re working against the language instead of with it. A simple rule of thumb: * If you’re creating a new array → use `map()` * If you’re performing side effects → use `forEach()` * If you’re filtering → use `filter()` instead of manual conditions Clean code isn’t about writing more lines. It’s about choosing the right abstraction for the job. Intentional developers let method names express meaning. So be honest—are you team `map()`, or still reaching for `forEach()` when transforming data? #JavaScript #CleanCode #FrontendDevelopment #WebEngineering #SoftwareCraftsmanship #CodeQuality #ReactJS

🧠 What is Callback Hell in JavaScript? When working with asynchronous operations in JavaScript, I initially faced something called Callback Hell. 👉 Callback Hell happens when multiple async functions are nested inside each other, making the code hard to read and maintain. ❌ Example of Callback Hell getUser(userId, function(user) { getOrders(user.id, function(orders) { getPayment(orders[0].id, function(payment) { getInvoice(payment.id, function(invoice) { console.log(invoice); }); }); }); }); Problems: • Deep nesting • Hard to debug • Difficult error handling • Poor scalability This pyramid structure is often called the “Pyramid of Doom.” ✅ Modern Solution — Async/Await try { const user = await getUser(userId); const orders = await getOrders(user.id); const payment = await getPayment(orders[0].id); const invoice = await getInvoice(payment.id); console.log(invoice); } catch (error) { console.error(error); } Benefits: ✔ Cleaner structure ✔ Better readability ✔ Centralized error handling ✔ Production-friendly code 🚀 Backend Learning Understanding async flow is critical in: • API development • Database queries • File handling • Third-party integrations Clean async code = Scalable backend systems. #JavaScript #NodeJS #BackendDevelopment #FullStackDeveloper #CleanCode

𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗧𝗵𝗲 𝗘𝘃𝗲𝗻𝘁 𝗟𝗼𝗼𝗽 JavaScript has a concept that powers almost everything it does: - Synchronous code - Asynchronous code You need to understand how JavaScript runs code. Imagine a worker who can only do one task at a time. This worker organizes tasks into categories: - Immediate work - Very important quick tasks - Tasks that can wait JavaScript does the same. Synchronous code runs line by line, in order. Example: console.log("Hello"); console.log("World"); Output: Hello World Asynchronous code allows tasks to run at the same time. Example: setTimeout(() => { console.log("Task finished"); }, 2000); This means "run this function after 2 seconds". JavaScript continues executing other code instead of waiting. JavaScript has the Event Loop, a manager that checks for work. It organizes tasks into two queues: - Microtasks (very important small tasks) - Macrotasks (normal asynchronous tasks) Let's look at an example: console.log("Start"); setTimeout(() => { console.log("Timeout"); }, 0); Promise.resolve().then(() => { console.log("Promise"); }); console.log("End"); Output: Start End Promise Timeout The Event Loop explains this result. JavaScript executes tasks in this order: - Synchronous code - Microtasks (Promises) - Macrotasks (Timers, setTimeout) Understanding the Event Loop helps you work with API requests. Many bugs happen because developers misunderstand asynchronous tasks. Once you understand the Event Loop, these problems become easier to solve. Try to predict the output of this code: console.log("A"); setTimeout(() => console.log("B"), 0); Promise.resolve().then(() => console.log("C")); console.log("D"); Use the rule we learned. Which one runs first? Write your answer in the comments. Source: https://lnkd.in/gbAJefcw

https://lnkd.in/d6hCZiBy << ...Iterator helpers in JavaScript gives us a native, lazy alternative that’s especially relevant for dealing with large datasets, streams, and UI-driven logic... >>

JavaScript this keyword doesn't have to be a mystery. I just published a blog covering the 4 ways this gets its value: 🔹 Implicit: obj.method() 🔹 Explicit: .call(), .apply(), .bind() 🔹 New: const user = new User() 🔹 Default: The fallback (Window/Undefined) If you've ever struggled with scope or context, this one is for you. Check it out: https://lnkd.in/gKk4GYGp Special thanks to Hitesh Choudhary for giving me the question that started this all and to Akash Kadlag, for explaining and making the concepts easy to understand.

𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗖𝗮𝗹𝗹, 𝗔𝗽𝗽𝗹𝗱, 𝗮𝗻𝗱 𝗕𝗶𝗻𝗱 Understanding call, apply, and bind is key to mastering JavaScript function context. You need to know how these work to write better code. In JavaScript, the value of this depends on how a function is called. It does not depend on where the function is defined. For example: const user = { name: "Jon", job: "engineer", intro() { console.log(`${this.name} is ${this.job}`); } }; user.intro(); // Jon is engineer If you want to use a function with another object, you can use call, apply, or bind. Here's how they work: - call() invokes a function immediately and allows you to pass arguments one by one. - apply() is similar to call(), but it accepts arguments as an array. - bind() returns a new function with this permanently bound to the object. You can use call() like this: const user1 = { name: "Jon" }; const user2 = { name: "Ron" }; function intro(job) { console.log(`${this.name} is ${job}`); } intro.call(user1, "engineer"); // Jon is engineer intro.call(user2, "teacher"); // Ron is teacher apply() works like call(), but with an array of arguments: function greet(city, country) { console.log(this.name + " is from " + city + ", " + country); } greet.apply(user1, ["Paris", "France"]); // Jon is from Paris, France bind() does not invoke the function immediately. It returns a new function with this bound to the object: const jonIntro = intro.bind(user1, "engineer"); jonIntro(); // Jon is engineer Source: https://lnkd.in/geM7JjCh

Day 12: Promises in JavaScript Callback Hell made async code messy… 😵💫 So JavaScript introduced something better — #Promises 🔹 What is a Promise? A Promise is an object that represents the eventual completion (or failure) of an asynchronous operation. It has 3 states: 🟡 Pending 🟢 Fulfilled 🔴 Rejected 🔹 Basic Example const promise = new Promise((resolve, reject) => { let success = true; if (success) { resolve("Data fetched successfully"); } else { reject("Error occurred"); } }); promise .then(result => console.log(result)) .catch(error => console.log(error)); 🔹 Why Promises are Better than Callbacks? ✅ Avoid Callback Hell ✅ Cleaner chaining using .then() ✅ Better error handling with .catch() ✅ More readable async flow 🔹 Promise Chaining fetchData() .then(data => processData(data)) .then(result => saveData(result)) .catch(error => console.log(error)); 👉 Each .then() returns a new promise 👉 Errors bubble down to .catch() 🔥 Why Important? ✔️ Core concept before learning async/await ✔️ Frequently asked in interviews ✔️ Used in APIs, fetch, database calls #Javascript #Promises #Webdevelopment #frontend #LearnInPublic

🚨 Is .then().catch() dead after try...catch in JavaScript? Short answer: No. Both are alive and useful. The real difference is how you structure asynchronous code. 🔹 1️⃣ Promise style — .then().catch() This was the original way to handle async operations with Promises. Example: fetch("/api/data") .then(res => res.json()) .then(data => console.log(data)) .catch(err => console.error(err)); ✅ Best when: You want simple promise chains Writing functional pipelines Handling single async operations 🔹 2️⃣ Async/Await style — try...catch Modern JavaScript introduced async/await, making async code look like synchronous code. Example: async function getData() { try { const res = await fetch("/api/data"); const data = await res.json(); console.log(data); } catch (err) { console.error(err); } } ✅ Best when: You have multiple sequential async calls You want cleaner, readable code Handling complex error flows 💡 Key Insight async/await is actually built on top of Promises. So .then() and .catch() are still working under the hood. 👉 It's not about which one is better. 👉 It's about which one fits the situation. 📌 Quick Rule Small async chain → .then().catch() Complex async logic → async/await + try...catch JavaScript keeps evolving, but understanding both patterns makes you a stronger developer. #javascript #webdevelopment #frontend #nodejs #asyncawait #promises #coding #softwaredevelopment #100DaysOfCode