A deep dive into Node.js internals — V8, libuv, Turbofan JIT, and why TypeScript is not just about DX.
In the age of vibe coding — where anyone can spin up a full-stack app by chatting with an AI agent — I decided to go against the trend and look down, not up.
Who hasn't seen JavaScript code at this point? It's everywhere. But if today everyone can create software, what sets us developers apart? I'd argue it's understanding why things work, not just that they work.
So I spent a few days digging into TypeScript, Node.js, V8, and libuv at a low level. Here's what I found.
Node.js: A Wikipedia Definition That Tells You Nothing
We all know the textbook one:
Node.js is an open-source, cross-platform, event-driven JavaScript runtime built on Google Chrome's V8 engine.
Cool. But what does that actually mean? How does the most widely used language in the world get executed on a server?
It's C All the Way Down
Here's the first thing that surprised me: Node.js is made of C and C++ programs. And that's not a coincidence.
JavaScript is a web scripting language — it was born inside the browser. By itself, it can't touch your filesystem, open a network socket, or spawn a process. It has no idea what an operating system even is.
So how does it do all of that in Node? Two pieces of software make it happen:
- V8 — Google's JavaScript engine, written in C++. It parses, compiles, and executes your JS code.
- libuv — a C library that provides asynchronous I/O and acts as the bridge between JavaScript and the operating system.
V8 + libuv = Node.js. That's the whole recipe.
"Single-Threaded" — But Not How You Think
Yes, Node is single-threaded by design. Your JavaScript code runs on one thread — the event loop.
But Node is not limited to a single thread. Under the hood, libuv maintains a thread pool (4 threads by default) to handle blocking I/O operations — things like filesystem reads, DNS lookups, and compression. These run in the background and return results to the event loop when they're done.
On top of that, you can explicitly spawn worker threads or child processes when you need true parallelism.
So the "Node is single-threaded" take is only half the story.
Why TypeScript Is Not Just a DX Choice
In 2026, why would you still write plain JavaScript instead of TypeScript? Many teams adopt TS for the developer experience — autocompletion, refactoring, catching bugs before runtime. That's reason enough.
But there's a deeper, performance-level argument for TypeScript that most people never talk about. It comes down to how V8 compiles your code.
V8's Compilation Pipeline
When V8 runs your JavaScript, it doesn't just interpret it line by line. Here's the simplified flow:
- Ignition (interpreter) — parses your code and generates bytecode. Fast startup, slow execution.
- Sparkplug — a baseline compiler that produces slightly optimized machine code without heavy analysis.
- Turbofan (JIT compiler) — the heavy hitter. It monitors which functions are called often ("hot functions"), profiles their behavior, and compiles them into highly optimized machine code, bypassing bytecode entirely.
The key: Turbofan's optimizations depend on type consistency. If a function always receives the same shapes and types, V8 can make aggressive assumptions and generate fast machine code.
But if the types change mid-execution? V8 has to deoptimize — throw away the optimized code and fall back to the slower bytecode path. This is expensive.
The Code That Proves It
// GOOD: consistent types → Turbofan optimizes aggressively
function addNumbers(a: number, b: number): number {
return a + b;
}
// V8 sees this function called thousands of times
// always with numbers → marks it as "hot" → compiles to
// optimized machine code
for (let i = 0; i < 100_000; i++) {
addNumbers(i, i + 1); // always numbers ✓
}
// BAD: inconsistent types → deoptimization
function add(a, b) {
return a + b;
}
// V8 profiles this, assumes numbers, optimizes...
for (let i = 0; i < 100_000; i++) {
add(i, i + 1);
}
// ...then this happens:
add("hello", " world"); // string?! → DEOPTIMIZE
// V8 discards the optimized machine code,
// falls back to bytecode interpretation,
// and has to re-profile from scratch
With TypeScript, you're enforcing type consistency at the source level. This means V8's profiler encounters monomorphic call sites — functions that always see the same types — far more often. Turbofan loves this. The result is faster, more stable machine code.
So TypeScript isn't just about catching bugs. It's about giving the engine what it needs to go fast.
TypeScript Helps Your AI Agent Too
Here's a thought that feels very 2026: types don't just help you — they help your AI coding agent.
When an agent generates or modifies code in a typed codebase, the type system acts as a set of guardrails. The agent can't silently pass a string where a number is expected, or return an object with a missing field. The compiler catches it immediately. In an untyped codebase, that same mistake slips through silently and shows up as a runtime bug three days later.
Types are essentially a contract — for humans, for V8, and now for AI agents. The more explicit your codebase is about its intent, the more reliably any contributor (human or not) can work within it.
Why Fundamentals Still Matter
Understanding how things work under the hood isn't just intellectual curiosity. It changes how you write code and how you think about the infrastructure running it.
When you know that libuv has a thread pool of 4, you understand why CPU-heavy tasks can block your Node process. When you know about Turbofan deoptimization, you think twice about writing functions with wildly inconsistent types.
Whether it's you writing the code or your AI agent — understanding what's happening under the surface is what lets you make informed decisions, optimize where it matters, and justify your architectural choices.
Bonus: Node.js Isn't the Only Game in Town
Node isn't the only JavaScript runtime out there. But one that caught my attention recently is Bun.
Bun is an all-in-one toolkit: runtime, test runner, bundler, and package manager — all packed into a single binary. It doesn't use V8. Instead, it's built on JavaScriptCore (the engine behind Safari) and written in Zig, a low-level systems language.
The performance numbers are hard to ignore: startup times around 5ms (vs Node's ~50ms), HTTP throughput up to 2-3x higher, and package installs that are 6-10x faster than npm. It also runs TypeScript natively — no transpilation step needed.
Is it mature enough to replace Node in production? For complex, battle-tested systems with deep dependency trees — probably not yet. But for new projects, CLI tools, or if you're curious and want to experiment with a modern frontend setup, Bun is absolutely worth a look.
Go Deeper
There's a lot more I could cover — the event loop phases, the microtask queue, how async/await interacts with libuv, V8's hidden classes and inline caches. If you have a few hours to spare, I'd encourage you to explore these topics. The deeper you go, the more the pieces connect — and the better engineer you become.
In an era where everyone can generate code, understanding what the code does at the machine level is what makes the difference.
If you found this useful or have anything to add, drop a comment — I'd love to hear what low-level topic you'd dig into next.
Top comments (3)
Great article
So if I understand, using typescript at the end helps because "we" as people who write the code need to stick to the types of a function and v8 can optimize that because it will always be the same input or is it something else happen under the hood?
Yes, you're right. Personally the mental modal should be, if I can use a strictly type language, there aren't reasons to don't use it.