JavaScript feels approachable because you can write a few lines and see results immediately, yet that simplicity masks deep complexity in how code is parsed, scheduled, and executed. This chapter introduces the idea that what you observe from your program depends not just on the language, but also on the engine that implements it and the host runtime that embeds the engine. It frames the book’s mission: to expose the underlying mechanics—event loops, queues, and runtime policies—so developers can reason about correctness and performance across environments.
A small “hello” puzzle demonstrates the pitfalls: identical code that mixes timers, microtasks, and runtime-specific hooks can print different outputs in different contexts. Running the same snippet under Node.js as CommonJS versus as an ECMAScript module, or in Deno or Bun, yields varying orders because each runtime defines when to drain microtasks, next ticks, and immediates, and even which APIs exist by default. These differences are largely host-defined (and sometimes version- or module-mode–dependent), while language-defined features like promises have consistent observable behavior but can still interact with host scheduling in surprising ways.
To explain these outcomes, the chapter separates concerns among the ECMAScript specification (language rules), JavaScript engines (parsing, compilation, execution), and host runtimes (I/O, timers, event loop, scheduling, available APIs). It shows how multiple queues—such as the microtask queue for promises and runtime-specific queues in Node.js—are orchestrated differently by each host, leading to real-world variability that can affect correctness and performance. The book positions itself as an owner’s manual for these internals, using Node.js as a baseline while contrasting other environments, and previews forthcoming deep dives into types, promises, streams, cryptography, and module systems.
An illustration of the phases of the Node.js Event Loop from the project documentation (https://nodejs.org/en/learn/asynchronous-work/event-loop-timers-and-nexttick). At the start of each iteration Node.js will first execute timers, then move on to calling pending callbacks, preparing for I/O, polling the operating system for I/O, then performing various checks and cleanup operations before starting over again at the top with timers.
Summary
Identical JavaScript code can yield different results in Node.js, Deno, and Bun due to differences in runtime implementation choices
The event loop controls execution order, with each runtime implementing different scheduling priorities
Language specifications define what must be consistent; implementations and hosts define what can vary
Understanding the distinction between language, implementation, and host behaviors prevents unexpected bugs
FAQ
What is the core takeaway from the “Hello” puzzle in Chapter 1?The puzzle shows that the order in which asynchronous JavaScript runs depends on the host runtime’s scheduling rules, not on the visual order of the code. Understanding queues like microtasks, nextTicks, and immediates—and when each runs—is essential to predict behavior and avoid performance and correctness bugs.Why can identical code produce different outputs across Node.js, Deno, Bun, and browsers?Each runtime has its own event loop design, supported queues, and drain order. For example, Node.js has nextTick and immediates queues; browsers do not have nextTick. Even within Node.js, module type (CommonJS vs ESM) changes startup/teardown and queue-drain timing. These host-defined differences lead to different observable results.How do microtasks, nextTicks, and immediates differ?- Microtasks: Language-defined, used by promises and queueMicrotask; can be drained many times within a single event loop turn.
- nextTick (Node.js): Host-defined queue drained before microtasks in Node.js; not available in browsers.
- Immediates (Node.js): Host-defined via setImmediate; typically run after I/O in the “check” phase. Not present in all runtimes by default.What is the event loop and why does it vary by runtime?The event loop schedules when JavaScript runs in response to events. Browsers tune it to keep the UI responsive and running continuously; Node.js optimizes for I/O, draining work quickly and exiting when there’s nothing left. Node’s loop has multiple phases (e.g., timers, poll, check), and the exact rules differ from other runtimes.How does switching from CommonJS to ESM in Node.js change behavior?Simply changing a file to ESM (e.g., .mjs) can alter when queues are drained and how startup/teardown run, yielding different output. In the chapter’s example, CommonJS prints “Hello”, while the ESM version prints “elHo” followed by a separate “l”. The module system changes scheduling details even with identical code.Why doesn’t Deno run the Node.js example unchanged, and why does Bun differ?Deno focuses on web compatibility and doesn’t expose all Node globals by default (e.g., setImmediate must be imported from node:timers or enabled with a flag). Bun embeds a different engine (JavaScriptCore) and has its own scheduling choices. Both aim for compatibility to varying degrees but don’t exactly match Node’s timing.What’s the difference between the language, the engine, and the host runtime?- Language (ECMAScript): The spec that defines core behavior (e.g., promises).
- Engine (e.g., V8, SpiderMonkey, JavaScriptCore): Implements the spec and optimizations.
- Host runtime (e.g., Node.js, Deno, browsers): Embeds the engine, provides APIs (I/O, timers), and controls scheduling/event loop behavior.What do “language-defined,” “implementation-defined,” and “host-defined” mean?- Language-defined: Must behave the same across all runtimes (e.g., promise semantics).
- Implementation-defined: Varies by engine but is similar across runtimes using the same engine.
- Host-defined: Varies by runtime; e.g., process.nextTick and setImmediate are Node-specific scheduling features.What does “scheduling” mean in JavaScript execution?Scheduling is how and when the runtime decides to run your code in response to events. Actions are placed on one or more queues (microtasks, timers, etc.), and the runtime determines the order and frequency of draining them. For example, a button’s onclick schedules code to run after the click; promises schedule continuations on the microtask queue.Why should developers care about these internals if JavaScript feels simple?Hidden scheduling details directly affect correctness and performance. Real systems can slow to a crawl or behave inconsistently across environments due to subtle misuse of promises, streams, or timers. Knowing how the language, engine, and runtime interact helps you write robust, portable, and faster code—and avoid relying on brittle timing assumptions.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
JavaScript in Depth ebook for free
