Yakov Moshel’s Post

𝐃𝐚𝐲 1/30 – 𝐍𝐨𝐝𝐞.𝐣𝐬 𝐒𝐞𝐫𝐢𝐞𝐬: 𝐖𝐡𝐚𝐭 𝐍𝐨𝐝𝐞.𝐣𝐬 𝐫𝐞𝐚𝐥𝐥𝐲 𝐢𝐬 (𝐛𝐞𝐲𝐨𝐧𝐝 𝐭𝐡𝐞 𝐝𝐞𝐟𝐢𝐧𝐢𝐭𝐢𝐨𝐧) Most people say: 👉 “Node.js is a JavaScript runtime built on Chrome’s V8 engine.” That’s correct… but honestly, it’s not useful in real-world discussions. Let’s understand it like an engineer 💡 𝐍𝐨𝐝𝐞.𝐣𝐬 𝐢𝐬 𝐍𝐎𝐓 𝐣𝐮𝐬𝐭 𝐚 𝐫𝐮𝐧𝐭𝐢𝐦𝐞 — 𝐢𝐭’𝐬 𝐚𝐧 𝐞𝐯𝐞𝐧𝐭-𝐝𝐫𝐢𝐯𝐞𝐧, 𝐧𝐨𝐧-𝐛𝐥𝐨𝐜𝐤𝐢𝐧𝐠 𝐬𝐲𝐬𝐭𝐞𝐦 𝐝𝐞𝐬𝐢𝐠𝐧𝐞𝐝 𝐟𝐨𝐫 𝐡𝐚𝐧𝐝𝐥𝐢𝐧𝐠 𝐜𝐨𝐧𝐜𝐮𝐫𝐫𝐞𝐧𝐭 𝐨𝐩𝐞𝐫𝐚𝐭𝐢𝐨𝐧𝐬 𝐞𝐟𝐟𝐢𝐜𝐢𝐞𝐧𝐭𝐥𝐲. What does that mean? 1. It uses a 𝐬𝐢𝐧𝐠𝐥𝐞-𝐭𝐡𝐫𝐞𝐚𝐝𝐞𝐝 𝐞𝐯𝐞𝐧𝐭 𝐥𝐨𝐨𝐩 2. It delegates heavy tasks (I/O, network, file operations) to the system 3. It doesn’t wait… it keeps moving 🔁 𝐑𝐞𝐚𝐥-𝐰𝐨𝐫𝐥𝐝 𝐞𝐱𝐚𝐦𝐩𝐥𝐞: Imagine your backend API is: 1. Reading files 2. Calling external APIs 3. Querying databases In traditional blocking systems: ➡ One request waits for another In Node.js: ➡ Multiple requests are handled 𝐰𝐢𝐭𝐡𝐨𝐮𝐭 𝐰𝐚𝐢𝐭𝐢𝐧𝐠 🧠 𝐒𝐢𝐦𝐩𝐥𝐞 𝐚𝐧𝐚𝐥𝐨𝐠𝐲: Node.js is like a smart manager: Assigns tasks to workers Doesn’t sit idle Keeps taking new tasks ⚠️ 𝐁𝐮𝐭 𝐡𝐞𝐫𝐞’𝐬 𝐭𝐡𝐞 𝐭𝐫𝐮𝐭𝐡 𝐦𝐨𝐬𝐭 𝐭𝐮𝐭𝐨𝐫𝐢𝐚𝐥𝐬 𝐬𝐤𝐢𝐩: Node.js is NOT always the best choice. ❌ CPU-heavy tasks (like image processing, large calculations) can block the event loop ❌ Poor async handling can still cause performance issues 🔥 𝐅𝐫𝐨𝐦 𝐦𝐲 𝐞𝐱𝐩𝐞𝐫𝐢𝐞𝐧𝐜𝐞: In one of my projects, instead of processing everything synchronously, we used 𝐪𝐮𝐞𝐮𝐞-𝐛𝐚𝐬𝐞𝐝 𝐚𝐬𝐲𝐧𝐜 𝐩𝐫𝐨𝐜𝐞𝐬𝐬𝐢𝐧𝐠 (similar to Service Bus pattern). This helped us: ✔ Avoid API timeouts ✔ Handle large workloads ✔ Improve system scalability ✅ 𝐓𝐚𝐤𝐞𝐚𝐰𝐚𝐲: Node.js shines when: ✔ You have I/O-heavy applications ✔ You need high concurrency ✔ You design it with async patterns correctly 📌 Tomorrow (Day 2): 𝐃𝐞𝐞𝐩 𝐝𝐢𝐯𝐞 𝐢𝐧𝐭𝐨 𝐄𝐯𝐞𝐧𝐭 𝐋𝐨𝐨𝐩 (𝐭𝐡𝐞 𝐡𝐞𝐚𝐫𝐭 𝐨𝐟 𝐍𝐨𝐝𝐞.𝐣𝐬) #NodeJS #BackendDevelopment #JavaScript #FullStack #SoftwareEngineering #SystemDesign

I spent months writing async Node.js code without really understanding it. Then a production bug taught me the event loop the hard way. Here's what you need to know: Node.js is single-threaded — but it handles thousands of concurrent requests without freezing. How? The event loop. It has 4 key parts: 1. Call Stack — Your sync code runs here, line by line. One thing at a time. 2. libuv Thread Pool — Async tasks (file I/O, HTTP requests) get offloaded here. Your code keeps running. 3. Microtask Queue — Promise callbacks live here. They run BEFORE anything else queued. 4. Macrotask Queue — setTimeout and setInterval callbacks wait here. This explains a classic JS gotcha: console.log('1') setTimeout(() => console.log('2'), 0) Promise.resolve().then(() => console.log('3')) console.log('4') Output: 1 → 4 → 3 → 2 The Promise fires before the setTimeout — even with a 0ms delay. Once you understand this, a whole category of async bugs just... disappears. What part of async JavaScript tripped you up most? Drop it below 👇 #NodeJS #JavaScript #WebDevelopment #SoftwareEngineering #FullStack

Everything was working… until production said otherwise 😅 One of the trickiest bugs in JavaScript is when your code is technically correct… but finishes in the wrong order. Many developers think: “If I use async/await, I’m safe.” Sadly… no 😄 async/await makes code look clean. It does NOT control which request finishes first. That’s where race conditions begin. Simple example: User searches “React” → Request 1 starts Immediately searches “Node.js” → Request 2 starts If Request 1 finishes later, old data can replace the new result. Now your UI confidently shows… the wrong answer. Classic. Same thing happens in Node.js too: ✔ Multiple API calls updating the same data ✔ Parallel requests overwriting each other ✔ Background jobs fighting like siblings Everything runs. Everything breaks. How to avoid it: ✔ Cancel old requests ✔ Ignore stale responses ✔ Use request IDs ✔ Debounce fast actions ✔ Handle backend concurrency properly Big lesson: async/await is syntax. Correct execution order is architecture. Very different things. Good code is not just: “It runs on my machine.” Good code is: “It runs correctly in production.” 😄 Have you ever debugged a race condition bug that made you question your life choices? 👇 #JavaScript #NodeJS #AsyncAwait #RaceConditions #FrontendDevelopment #BackendDevelopment #SoftwareEngineering #WebDevelopment

Nobody told me this when I started React. I learned props. I learned the state. I thought I understood both. I didn't. I was putting everything in state. User data. Config values. Things passed in from the parent. Didn't matter — if I needed it inside a component, it went into useState. It worked. Until it didn't. On a client project, I had a component receiving a userId from its parent. I was also storing that userId in local state. Then the parent updated. My local state didn't. Two different values. One component. Complete mess. The bug took me hours to find. The fix was deleting four lines of code. Here's what nobody told me: Props and state are not two ways to store data. They are two completely different things with two completely different jobs. Props are data that comes from outside. The parent owns it. The parent controls it. Your component just receives it and uses it. You don't store it. You don't copy it. You use it directly. State is data that lives inside. Your component owns it. Your component controls it. When it changes, the component re-renders. Nothing outside knows it exists unless you explicitly pass it down. One simple test I use now: Does this component own this data — or is it just receiving it from somewhere else? If it owns it → state. If it's receiving it → props. Use it directly. Never copy it into state. That one question has saved me from every props-vs-state bug I've ever faced. The bug I had on that client project? I was copying props into the state. The parent updated the prop. My state copy didn't follow. UI showed stale data. Classic mistake. Extremely common. Nobody warns you about it early enough. #React #JavaScript #Frontend #ReactJS #WebDevelopment #Programming #100DaysOfCode #SoftwareDevelopment

🚀 𝗗𝗮𝘆 𝟭: 𝗧𝘆𝗽𝗲𝗦𝗰𝗿𝗶𝗽𝘁 𝗙𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹𝘀 👉 Build a Strong Base TypeScript isn’t just “JavaScript with types”. It’s about writing code that is: ✔ Predictable ✔ Maintainable ✔ Bug-resistant 🔹 What problem does TypeScript solve? JavaScript → Dynamic → Errors at runtime ❌ TypeScript → Static → Errors during development ✅ 👉 Catch issues before your app runs. 🔹 Core Types You Must Know • string, number, boolean → basics • any → disables safety (avoid) • unknown → safe alternative • void → no return • never → never completes 🔹 Functions with Type Safety function add(a: number, b: number): number { return a + b; } 👉 Prevents invalid usage like passing strings. 🔹 Interfaces vs Types interface User { id: number; name: string; } type Status = "active" | "inactive"; ✔ Interface → object structure ✔ Type → unions & flexibility 🔹 Union Types (Real-world) type ApiStatus = "loading" | "success" | "error"; 👉 Perfect for handling UI states cleanly. 🔹 Strict Mode (Must Enable) "strict": true ✔ Prevents null errors ✔ Enforces better coding discipline 💡 Final Thought You can skip fundamentals… But your code won’t scale without them. ⏭️ Tomorrow: Generics, Utility Types & Real Power of TypeScript 🔥 #TypeScript #Frontend #Angular #CleanCode #SoftwareEngineering

JavaScript is easy. Until it isn't. 😅 Every developer has been there. You're confident. Your code looks clean. You hit run. And then: " Cannot read properties of undefined (reading 'map') " The classic JavaScript wall. Here are 7 JavaScript mistakes I see developers make constantly and how to fix them: 1. Not understanding async/await ⚡ → Wrong: | const data = fetch('https://lnkd.in/dMDBzbsK'); console.log(data); // Promise {pending} | → Right: | const data = await fetch('https://lnkd.in/dMDBzbsK'); | 2. Using var instead of let/const → var is function scoped and causes weird bugs → Always use const by default. let when you need to reassign. Never var. 3. == instead of === → 0 == "0" is true in JavaScript 😱 → Always use === for comparisons. Always. 4. Mutating state directly in React → Wrong: user.name = "Shoaib" → Right: setUser({...user, name: "Shoaib"}) 5. Forgetting to handle errors in async functions → Always wrap await calls in try/catch → Silent failures are the hardest bugs to track down 6. Not cleaning up useEffect in React → Memory leaks are real → Always return a cleanup function when subscribing to events 7. Treating arrays and objects as primitives → [] === [] is false in JavaScript → Reference types don't compare like numbers — learn this early JavaScript rewards the developers who understand its quirks. 💡 Which of these caught YOU off guard when you first learned it? 👇 #JavaScript #WebDevelopment #Frontend #FullStackDeveloper #React #Programming #CodingTips #Developer #Tech #Pakistan #LearnToCode #JS #SoftwareEngineering #100DaysOfCode #PakistaniDeveloper

🚀 Understanding Node.js Internals: Event Loop & Thread Pool This week, I took a deeper dive into how Node.js actually works behind the scenes — and it completely changed how I think about asynchronous code. 🔹 JavaScript in Node.js runs on a single thread 🔹 Yet it handles multiple tasks efficiently using the Event Loop 🔹 Heavy operations are offloaded to the Thread Pool (via libuv) Some key takeaways: Event Loop manages execution in phases (Timers, I/O, setImmediate, etc.) setTimeout(0) is not truly immediate setImmediate() behaves differently inside vs outside I/O process.nextTick() runs before the event loop even starts Understanding these concepts makes async behavior much more predictable and helps write better backend code. Would love to hear your thoughts or corrections 🙌! Blog Link : https://lnkd.in/gxBA4DeT #JavaScript #WebDev #LearnInPublic #Blog #libuv #EventLoop #ThreadPool #ChaiCode Thanks to Hitesh Choudhary, Piyush Garg, Jay Kadlag, Akash Kadlag for guidance 😊

🚀 Day 5/30 — Async/Await changed JavaScript forever Before async/await, we wrote: 𝘭𝘰𝘨𝘪𝘯𝘜𝘴𝘦𝘳() .𝘵𝘩𝘦𝘯(𝘨𝘦𝘵𝘖𝘳𝘥𝘦𝘳𝘴) .𝘵𝘩𝘦𝘯(𝘱𝘳𝘰𝘤𝘦𝘴𝘴𝘗𝘢𝘺𝘮𝘦𝘯𝘵) .𝘤𝘢𝘵𝘤𝘩(𝘩𝘢𝘯𝘥𝘭𝘦𝘌𝘳𝘳𝘰𝘳) Worked well… But async/await made asynchronous code feel natural: 𝘵𝘳𝘺 { 𝘤𝘰𝘯𝘴𝘵 𝘶𝘴𝘦𝘳 = 𝘢𝘸𝘢𝘪𝘵 𝘭𝘰𝘨𝘪𝘯𝘜𝘴𝘦𝘳(); 𝘤𝘰𝘯𝘴𝘵 𝘰𝘳𝘥𝘦𝘳𝘴 = 𝘢𝘸𝘢𝘪𝘵 𝘨𝘦𝘵𝘖𝘳𝘥𝘦𝘳𝘴(𝘶𝘴𝘦𝘳.𝘪𝘥); 𝘢𝘸𝘢𝘪𝘵 𝘱𝘳𝘰𝘤𝘦𝘴𝘴𝘗𝘢𝘺𝘮𝘦𝘯𝘵(𝘰𝘳𝘥𝘦𝘳𝘴); } 𝘤𝘢𝘵𝘤𝘩(𝘦𝘳𝘳){ 𝘤𝘰𝘯𝘴𝘰𝘭𝘦.𝘦𝘳𝘳𝘰𝘳(𝘦𝘳𝘳); } Cleaner. Easier to debug. Easier to maintain. 𝐁𝐮𝐭 𝐡𝐞𝐫𝐞’𝐬 𝐭𝐡𝐞 𝐦𝐢𝐬𝐭𝐚𝐤𝐞 𝐦𝐚𝐧𝐲 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫𝐬 𝐦𝐚𝐤𝐞👇 await getUsers(); await getOrders(); await getProducts(); ❌ Slow (runs sequentially) Better: await Promise.all([ getUsers(), getOrders(), getProducts() ]); ✅ Concurrent + faster 💡 Big lesson: Async/Await improved readability. Promise.all() improves performance. Small code decisions create big scalability differences. What do you prefer in production: Async/Await or .then() chains? #NodeJS #JavaScript #AsyncAwait #BackendDevelopment #SoftwareEngineering

𝟵𝟵% 𝗼𝗳 𝗝𝗦 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝘄𝗿𝗶𝘁𝗲 𝗮𝘀𝘆𝗻𝗰 𝗰𝗼𝗱𝗲 𝗱𝗮𝗶𝗹𝘆. 𝗕𝘂𝘁 𝗺𝗼𝘀𝘁 𝗰𝗮𝗻'𝘁 𝗲𝘅𝗽𝗹𝗮𝗶𝗻 𝘄𝗵𝘆 𝗶𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘄𝗼𝗿𝗸𝘀. 👇 I didn't either until I learned about the JavaScript Runtime Environment. Here's the mental model that changed everything for me: JavaScript by itself is just a language. Runtime = Engine + APIs + Event Loop 🔥 What's actually running under the hood: ⚙️ JS Engine (V8) → converts code to machine code 📞 Call Stack → runs functions one by one 🌐 Web APIs → setTimeout, DOM, fetch (NOT part of JS itself!) 📬 Callback Queue → stores async callbacks ⚡ Microtask Queue → Promises, higher priority 🔄 Event Loop → the brain connecting everything The flow: Code → Call Stack → Web APIs → Queue → Event Loop → Call Stack Right now, try this 👇 console.log("Start"); setTimeout(() => console.log("Async"), 0); console.log("End"); Output → Start, End, Async 🤯 Even with 0 ms delay, "Async" prints LAST. That's the Event Loop doing its job. 🧠 Interview tip: Q: Why can JS handle async if it's single-threaded? A: The Runtime provides Web APIs + Event Loop + Queues — not the language. If this helped, repost ♻️ to help another developer. Follow Amit Prasad for daily updates on JavaScript and DSA 🔔 💬 Comment: Did you know that setTimeout 0ms still runs last? #JavaScript #WebDevelopment #Frontend #NodeJS #100DaysOfCode #DSA #Developer #CodingLife #TechLearning