Yesterday I broke down V8 and libuv, the first two pillars of Node.js.If you missed it, go read that first. Today we close the loop with the third pillar and a benchmark that makes everything click. Still with me? Good. Let us open the black box. PILLAR 3: C++ Bindings — The Bridge Between Your JS and the Machine When you write const fs = require('fs'), you are not loading a JavaScript file. You are loading a JavaScript interface wired directly into C++ code.Here is the full journey of a single fs.readFile() call: Your JS calls readFile Node's core module drops into C++ via the bindings C++ prepares the request and hands it to libuv. libuv sends it to a worker thread in the thread pool Your JavaScript keeps running. Zero waiting. The worker thread reads the file from disk It notifies libuv when done libuv queues the result for the event loop On the next loop tick your callback fires with the data That entire chain happens in milliseconds. And while it is running your server has already started handling new incoming requests. Now here is the number that makes all three pillars make sense together. Two servers. 10 concurrent requests. Each takes 2 seconds to complete. Blocking server: handles them one by one. Total time: 20 seconds. Node.js server: accepts all 10 instantly, finishes all 10 together. Total time: 2 seconds. Same hardware. Same workload. 10x faster. One thread. That is V8 compiling your code fast, libuv handling the async work, and C++ bindings connecting the two. All three working together. And this is exactly why the golden rule of Node.js exists. Never block the event loop. The moment your main thread gets stuck on heavy synchronous work, that 2 second result becomes 20 seconds again. Every advantage disappears instantly. Now you understand the architecture. Tomorrow I will show you what happens when you trust that architecture too blindly, and the day 11 lines of code broke the entire JavaScript ecosystem. Follow so you do not miss it. #NodeJS #JavaScript #WebDevelopment #Backend #SoftwareEngineering #Programming #TechEducation
Node.js Architecture: C++ Bindings, V8, and libuv
More Relevant Posts
-
Understanding How require() Works in Node.js Today I deeply understood something that we use daily… but rarely truly understand: How modules and require() actually work in Node.js. Let’s break it down in a very simple way. Step 1: Why Do Modules Even Exist? Imagine building a big application in a single file. Variables would clash Code would become messy Debugging would be painful So we divide code into separate files. Each file = one module. But here’s the real question: If I create a variable in one file, should every other file automatically access it? No. That would create chaos. So Node.js protects each file. Step 2: Modules Work Like Functions We already know this: function test() { let secret = 10; } You cannot access secret outside the function. Why? Because functions create a private scope. Node.js uses the exact same idea. Behind the scenes, every file is wrapped like this: (function (exports, require, module, __filename, __dirname) { // your entire file code lives here }); This wrapper function creates a private scope. That’s why variables inside a module don’t leak outside. Step 3: How require() Works Internally When you write: const math = require('./math'); Node.js does these steps: 1. Resolve the file path It finds the correct file. 2. Load the file Reads the code from disk. 3. Wrap it inside a function To protect variables. 4. Execute the code Runs the module once. 5. Store it in cache So it doesn’t execute again. 6. Return module.exports Only what you explicitly export is shared. Why Caching Is Important Modules are executed only once. After the first require(): Node stores the result. Future requires return the cached version. No reloading, no re-execution. This improves performance and makes modules behave like singletons. #NodeJS #JavaScript #BackendDevelopment #WebDevelopment #FullStackDevelopment
To view or add a comment, sign in
-
-
Day 90 of me reading random and basic but important dev topicsss...... Today I read about the File Object in JavaScript As web applications become more robust, handling file uploads, drag-and-drop interfaces, and binary data is an absolute must for modern frontend development. What is a File? At its core, a File object is just a specific type of Blob (Binary Large Object) that is extended with filesystem-related capabilities. Because it inherits from Blob, it has access to all the same properties, but adds two crucial pieces of OS-level data: * name: The file name string (e.g. "profile.png"). * lastModified: The timestamp of the last modification (integer date). How do we get a File object? There are two primary ways we encounter files in the browser: 1. User Input (The Common Way) Most of the time, the OS provides this data when a user interacts with an <input type="file"> or a drag-and-drop interface. function handleUpload(input) { // input.files is an array-like object, as users can select multiple files let file = input.files[0]; console.log(`Name: ${file.name} | Modified: ${file.lastModified}`); } 2. The Constructor (The Programmatic Way) You can manually construct a file using: new File(fileParts, fileName, [options]) * fileParts: An array of Blob, BufferSource, or String values. * fileName: The name of your new file. * options: An optional object where you can pass a custom lastModified timestamp. Pro-Tip: Sending files to the backend is incredibly seamless. Modern network APIs like fetch and XMLHttpRequest natively accept File objects in their payload! You don't always have to parse them first. Keep Learning!!!! #JavaScript #WebDevelopment #Frontend #SoftwareEngineering #CodingTips
To view or add a comment, sign in
-
-
A tale of two JavaScript patterns and the bugs that catch you out 🐛 I've been revisiting the two main ways to create custom objects in JavaScript. Both achieve the same goal. Both have traps. Here's what I found: ES6 Class class Character { constructor(name) { this.name = name this.powers = [] } addPowers(power) { this.powers.push(power) console.log(`${this.name} has ${this.powers} Powers!`) } } Methods live outside the constructor, inside the class body. They land on the prototype automatically so every instance shares one copy rather than each carrying its own. Constructor Function function Character(name) { this.name = name this.powers = [] this.addPowers = function(power) { this.powers.push(power) console.log(`${this.name} has ${this.powers} Powers!`) } } Easy gotcha: write function addPowers() instead of this.addPowers = and the method becomes a private inner function completely invisible outside the constructor. Your code won't error on creation, it'll just silently fail when you try to call it. The class syntax is cleaner and harder to get wrong. But understanding constructor functions teaches you what's actually happening under the hood and makes legacy codebases far less scary. Worth noting: there is a third way Object.create() but I've not covered it here. It gives you very fine-grained control over the prototype chain, but it's significantly more verbose and rarely the first tool you'd reach for. Both patterns. Both worth knowing. Have you been caught out by either of these? Let me know below 👇 #JavaScript #WebDevelopment #CodingTips #OOP #LearnToCode #JSDevs #SoftwareEngineering
To view or add a comment, sign in
-
If JavaScript is single‑threaded, how does it still handle Promises, API calls, and Timers without blocking the application? The answer lies in the Event Loop. Let’s take a simple example: What would be the output of the below code? console.log("Start"); setTimeout(() => { console.log("Timeout"); }, 0); Promise.resolve().then(() => { console.log("Promise"); }); console.log("End"); Some may guess the output to be: Start End Timeout Promise But the actual output is: Start End Promise Timeout So what is happening behind the scenes? 🔵 Synchronous Code Being synchronous, console.log("Start") and console.log("End") run immediately in the Call Stack. 🔵 Promises Resolved promises go to the Microtask Queue which is executed next. 🔵 setTimeout Timer callbacks go to the Macrotask Queue, even if the delay is '0ms', which is executed last. ✅ Simple flow to remember Synchronous Code → Promises (Microtasks) → setTimeout (Macrotasks) So even with 0 delay, Promises will always execute before setTimeout. Understanding this small but important detail will help developers debug async behavior and write more predictable JavaScript applications. #javascript #webdevelopment #eventloop #asyncprogramming
To view or add a comment, sign in
-
🚨 Most developers get this wrong about the JavaScript Event Loop What do you think this prints? 👇 console.log("Start"); setTimeout(() => console.log("Timeout"), 0); console.log("End"); Many people expect: ❌ Start ❌ Timeout ❌ End But the actual output is: ✅ Start ✅ End ✅ Timeout Why? 🤔 Because JavaScript is single-threaded and uses the Event Loop to handle async tasks. Here’s what really happens behind the scenes: 1️⃣ console.log("Start") → runs immediately in the Call Stack 2️⃣ setTimeout() → moves to Web APIs 3️⃣ console.log("End") → runs next (still synchronous) 4️⃣ Timer finishes → callback goes to Callback Queue 5️⃣ Event Loop pushes it to the Call Stack when it's empty 6️⃣ console.log("Timeout") finally runs 💡 Even setTimeout(..., 0) is never truly instant. If you understand this concept, debugging async JavaScript becomes 10x easier. 💬 Comment “EVENT LOOP” if you want a deeper breakdown with Promises & Microtasks. #javascript #webdevelopment #nodejs #frontend #backend #programming #eventloop #coding
To view or add a comment, sign in
-
-
JavaScript Arrow Functions → the modern, concise way to write functions! Classic: function add(a, b) { return a + b; } Arrow style (shorter & sweeter): const add = (a, b) => a + b; Even cooler shortcuts: Single param? Skip parentheses → x => x * 2 No params? Use empty () → () => console.log("Hi!") Multi-line? Add curly braces + return → (x, y) => { return x + y; } Biggest game-changer: lexical this binding No more .bind(this) headaches in callbacks, React handlers, setTimeout, promises, array methods (.map/.filter), etc. Arrow functions inherit this from the surrounding scope — clean & predictable! 🔥 When NOT to use them: Object methods (when you need dynamic this) Constructors (no prototype, can't use new) Arrow functions = cleaner code + fewer bugs in modern JS. Who's team arrow all the way? #JavaScript #ArrowFunctions #ES6 #CodingTips #WebDevelopment #ReactJS #Frontend #Programming #100DaysOfCode #DevCommunity
To view or add a comment, sign in
-
-
💡 JavaScript Tip: || vs ?? Many developers use || to set default values in JavaScript. But this can silently introduce bugs. Example: console.log(false || "temp"); // "temp" console.log(null || "temp"); // "temp" console.log(undefined || "temp"); // "temp" Why? Because || treats ANY falsy value as missing: false, 0, "", null, undefined, NaN Now look at the Nullish Coalescing operator (??): console.log(null ?? "temp"); // "temp" console.log(undefined ?? "temp"); // "temp" console.log(false ?? "temp"); // false ?? only replaces: null and undefined. Real example: let count = 0; console.log(count || 10); // 10 ❌ console.log(count ?? 10); // 0 ✅ ✔ Use || when you want to replace all falsy values ✔ Use ?? when you only want to replace null or undefined Small operator — but it can prevent real bugs in production. Do you usually use || or ?? for defaults? 🤔 #JavaScript #WebDevelopment #Frontend #Programming #SoftwareDevelopment
To view or add a comment, sign in
-
-
𝗪𝗵𝘆 𝘁𝘆𝗽𝗲𝗼𝗳 𝗻𝘂𝗹𝗹 𝗶𝘀 "𝗼𝗯𝗷𝗲𝗰𝘁" — 𝗧𝗵𝗲 𝟯𝟬-𝗬𝗲𝗮𝗿 𝗕𝘂𝗴 𝗧𝗵𝗮𝘁 𝗪𝗼𝗻’𝘁 𝗗𝗶𝗲 🐛 If you’ve ever debugged JavaScript and seen typeof null === 'object', you probably thought your code was broken. It’s not you. It’s one of the oldest "mistakes" in web history. Here’s the deep dive into why this quirk exists and why we’re stuck with it forever: 𝟭. 𝗧𝗵𝗲 "𝟭𝟬-𝗗𝗮𝘆" 𝗢𝗿𝗶𝗴𝗶𝗻 𝗦𝘁𝗼𝗿𝘆 ⏱️ In 1995, Brendan Eich created JavaScript in just 10 days. In that rush, the engine's internal structure used a "type tag" system to identify data. ● 𝗢𝗯𝗷𝗲𝗰𝘁𝘀 were assigned the tag 000. ● 𝗻𝘂𝗹𝗹, representing a null pointer, was represented as all zeros (0x00). Because the engine checked for the 000 tag to identify objects, and null consists entirely of zero bits, the typeof operator incorrectly flagged it as an object. 𝟮. 𝗧𝗵𝗲 𝗔𝘁𝘁𝗲𝗺𝗽𝘁𝗲𝗱 𝗙𝗶𝘅 🛠️ There was actually a proposal to "fix" this in ECMAScript 6 so that typeof null would return 'null'. So, why didn't it happen? 𝟯. 𝗧𝗵𝗲 "𝗗𝗼𝗻'𝘁 𝗕𝗿𝗲𝗮𝗸 𝘁𝗵𝗲 𝗜𝗻𝘁𝗲𝗿𝗻𝗲𝘁" 𝗥𝘂𝗹𝗲 🌐 Backward compatibility is the golden rule of the web. Millions of websites and legacy libraries rely on this specific bug for their logic. Changing it now would "break the internet," causing countless sites to crash. As Brendan Eich himself noted: “𝘐𝘵’𝘴 𝘵𝘰𝘰 𝘭𝘢𝘵𝘦 𝘵𝘰 𝘧𝘪𝘹.” 𝗧𝗵𝗲 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆 𝗳𝗼𝗿 𝗗𝗲𝘃𝘀: ✅ Never use typeof to check for null. ✅ Always use strict equality: myVar === null. ✅ Pro Tip: To check if something is actually a valid object, use: myVar !== null && typeof myVar === 'object'. JavaScript isn’t perfect, but its quirks are what make its history so fascinating. What’s your "favorite" JavaScript bug or quirk? Let’s discuss in the comments! 👇 #JavaScript #WebDevelopment #Programming #SoftwareEngineering #CodingLife #TechHistory #Frontend
To view or add a comment, sign in
-
-
🚀JavaScript is single-threaded… yet Node.js handles thousands of concurrent requests. How? JavaScript is single-threaded. So how does Node.js handle thousands of asynchronous operations like file reads, database calls, timers, and network requests without blocking the application? While learning Node.js internals, I tried to break this down with a simple architecture diagram. JavaScript runs inside the V8 engine and executes code line by line using a single call stack. This means only one piece of JavaScript code runs at a time. But when operations like reading a file, making an API request, or starting a timer happen, Node.js doesn't block the main thread waiting for the result. Instead, these operations are delegated to another layer that interacts with the operating system and manages asynchronous tasks. Once the operation finishes, the result is placed in a queue and executed when the call stack becomes free. This is what makes Node.js capable of handling many concurrent operations efficiently. I drew the architecture to understand the flow: JavaScript (Call Stack) → Node.js APIs → Async I/O Layer → Operating System → Event Loop → Callback Execution Two questions for backend developers: 1: What library powers asynchronous I/O and the event loop in Node.js? 2: Which programming languages are used to build the V8 engine, Node.js runtime, and the async I/O layer behind it? Drop your answers in the comments. #NodeJS #JavaScript #BackendDevelopment #AsyncProgramming #EventLoop #WebDevelopment #Libuv #react #mern
To view or add a comment, sign in
-
-
🚀 A JavaScript forEach() Mistake At first glance, this looks correct: const numbers = [1, 2, 3, 4]; const result = numbers.forEach(num => num * 2); console.log(result); Expected: [2, 4, 6, 8] Actual output: undefined Why? Because forEach() does not return a new array. It only executes a function for each element. So result becomes undefined. If you want to transform data, use map(). ✅ Correct approach: const numbers = [1, 2, 3, 4]; const result = numbers.map(num => num * 2); console.log(result); Now the output is: [2, 4, 6, 8] Small difference in method. Big difference in behavior. In JavaScript, choosing the right array method matters more than the logic itself. What array method confused you the most when you started? #javascript #frontenddeveloper #webdevelopment #coding #softwareengineering
To view or add a comment, sign in
-
More from this author
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development