Prevent Duplicate Function Calls with Once Utility in JavaScript

⚡ A Common JavaScript Misconception About the Event Loop Many developers think: "setTimeout(fn, 0) runs immediately." That’s incorrect. Even with 0 milliseconds, the callback still goes through the Event Loop cycle. Example: console.log("A"); setTimeout(() => console.log("B"), 0); Promise.resolve().then(() => console.log("C")); console.log("D"); Output: A D C B Why? Because JavaScript has two queues: 🔹 Microtask Queue → Promises, MutationObserver 🔹 Callback Queue → setTimeout, setInterval The Event Loop always processes microtasks first. Understanding this difference is critical when debugging async behavior in real applications. Master the Event Loop → Master asynchronous JavaScript. #javascript #asyncjavascript #webdevelopment #frontend #mernstack

💡 JavaScript Tip: Closures are one of the most powerful — and most misunderstood — concepts in JS. A closure is simply a function that remembers the variables from its outer scope, even after that scope has finished executing. Here's a classic example: function makeCounter() {  let count = 0;  return function () {   count++;   return count;  }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 The inner function has "closed over" the count variable — it keeps it alive and private. Why does this matter in real projects? → Data privacy (no need to expose variables globally) → Factory functions & currying → Event handlers that remember state → Memoization & caching Once you truly understand closures, a lot of JavaScript starts making sense. ♻️ Repost to help someone struggling with JS fundamentals. #JavaScript #WebDevelopment #CleanCode #Frontend #CodingTips

Don't do JavaScript. I mean it. The browser is a highly optimized engine written in C++, Rust, and C. It parses HTML. It diffs the DOM. It handles routing, focus, accessibility, scroll, history. It compresses repeated patterns with Brotli by factors of thousands. It is insanely good at this. And we keep replacing it. With JavaScript. ◆ How we got here Servers used to be slow. Threading was expensive. So we pushed logic to the client. SPAs made sense — in 2010. That constraint is gone. The complexity stayed. And quietly, over years, frameworks started re-implementing the browser itself. Virtual DOM. Client router. Hydration. State machines. JSON APIs just to feed them. We're not solving data problems anymore. We're solving framework problems. ◆ The forgotten principle: Progressive Enhancement Start with HTML that works. Always. No JavaScript required. Then layer interactivity on top — not as a dependency, but as an improvement. A page that works without JS and flies with it. That's not a compromise. That's good engineering. ◆ What the fast path actually looks like → Render HTML on the server — fully functional, accessible, indexable → Stream updates over a single SSE connection → Let the browser do diffing, layout, rendering → Repeated HTML over SSE + Brotli is often cheaper than your clever JSON diff → Add ~10 KB of Datastar for local state and reactivity on top → No build step — easier DevOps, faster iteration No virtual DOM. No hydration step. No client router. The server stays the source of truth. JS enhances — it doesn't own. ◆ Measure, don't vibe If one approach is 30–40x faster, uses less memory, less bandwidth, and less code — be willing to throw the old one away. The web was never slow. We just forgot how to use it. Delaney Gillilan explains this better than anyone — link in comments 👇 #JavaScript #ProgressiveEnhancement #WebDevelopment #Datastar #Hypermedia #SSE #CraftCMS

Day 19 of #30DaysOfJavaScript: Built a Simple Notes App! Started with a clean architecture. DOM elements mapped to variables for easy reference. Implemented CRUD operations: create notes with unique IDs (using timestamp + random string), open/edit existing notes, save to localStorage, and delete with confirmation. Real-time search filters notes by title and content using .includes() and .toLowerCase(). Built XSS protection by sanitizing HTML special characters before rendering to prevent injection attacks. Keyboard shortcuts added for power users Ctrl+N creates a note, Ctrl+S saves instantly. Used event delegation and localStorage API for persistent data storage across sessions. Every note tracks its updatedAt timestamp. The UI shows live previews with metadata. Pure vanilla JS—no frameworks, no dependencies. Fast, lightweight, and production-ready. Live: https://lnkd.in/dmsPwaJp #JavaScript #WebDevelopment #FrontendCoding #30DaysOfJS #VanillaJS #localStorage #Netlify

🧠 Day 4 of 21 days challenge JavaScript Hoisting 🤯 // var → undefined // let/const → error Why different behavior? Hoisting is a JavaScript behavior where variable and function declarations are moved to the top of their scope before execution. Only declarations are hoisted, not initializations. For easy understanding :- Hoisting = moving declarations to top var is hoisted with undefined let & const are hoisted but not initialized 👉 That’s why var gives undefined but let/const give error For example :- Normal code : console.log(score); // undefined var score = 90; JS will do this internally: var score; // first reserve console.log(score); // undefined score = 90; // then assign value This changed how I understand variable behavior 🚀 #JavaScript #Hoisting #Frontend

JavaScript closures are one of those concepts that seem confusing at first but are incredibly powerful. At a basic level, a closure allows a function to remember variables from its outer scope, even after that scope has finished executing. Understanding this makes patterns like callbacks and hooks much clearer. Source: MDN Web Docs – Closures https://lnkd.in/gZsRizzt

🚨 JavaScript Hoisting – Something Most Developers Still Misunderstand Most developers say: 👉 “JavaScript moves variables to the top of the scope.” But that’s not actually what happens. Let’s test this 👇 console.log(a); var a = 10; Output: undefined Now try this: console.log(b); let b = 20; Output: ReferenceError: Cannot access 'b' before initialization 💡 Why the difference? Both var and let are hoisted. But the real difference is initialization timing. ✔ var is hoisted and initialized with undefined during the creation phase. ✔ let and const are hoisted but stay inside the Temporal Dead Zone (TDZ) until the line where they are declared. That’s why accessing them before declaration throws an error. 👉 So technically: JavaScript doesn’t “move variables to the top”. Instead, the JavaScript engine allocates memory for declarations during the creation phase of the execution context. Small detail. But it explains a lot of confusing bugs. 🔥 Understanding this deeply helps when debugging closures, scope issues, and async code. #javascript #frontend #webdevelopment #reactjs #coding #softwareengineering

JavaScript is single-threaded… yet it handles timers, API calls, and user events at the same time. 🤯 How? Meet the Event Loop 🔁 — the system that keeps JavaScript running smoothly. Here’s the simple flow: 🧠 Call Stack – Executes synchronous code first 🌐 Web APIs – Handles async tasks like setTimeout, fetch, DOM events 📥 Queues – Completed tasks wait here to run But there’s a twist 👇 ⚡Microtask Queue (High Priority) Examples: Promise.then(), queueMicrotask() ⏳ Macrotask Queue (Lower Priority) Examples: setTimeout, setInterval, DOM events When the stack is empty, the Event Loop checks: 1️⃣ Microtasks first 2️⃣ Then Macrotasks Example: console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4); Output 👇 1 → 4 → 3 → 2 Because Promises run before setTimeout. Understanding this small concept can save you hours of debugging async code.🚀 Yogita Gyanani Piyush Vaswani #JavaScript #WebDevelopment #AsyncProgramming #FrontendDevelopment #EventLoop #CodingConcepts

⚛️ React 19 introduced a hook called use() that simplifies async data fetching. Instead of writing useState + useEffect, you can read a Promise directly. Example: const product = use(fetchProduct()) If the Promise is still pending, React pauses rendering and shows the nearest Suspense fallback. <Suspense fallback={<Loading />}> <ProductPage /> </Suspense> Before React 19, loading data usually looked like this: const [product, setProduct] = useState(null) useEffect(() => { fetchProduct().then(setProduct) }, []) Which meant managing: • useState • useEffect • loading states With use(), React handles this with Suspense. When the Promise resolves, rendering continues automatically. No loading state. No effect. Less boilerplate. A small hook. But a big improvement in how React handles async rendering. #React #React19 #FrontendDevelopment #WebDevelopment #JavaScript