JavaScript may seem effortless to pick up, but that simplicity hides a great deal of complexity in how code is actually parsed, scheduled, and executed. The chapter opens by showing that even a small “hello” puzzle can behave differently depending on the runtime, module format, and queue semantics involved, which makes it clear that understanding JavaScript at a deeper level requires looking beyond the surface of the language.
The key lesson is that the same source code can produce different results in Node.js, Deno, Bun, browsers, and other environments because each host runtime and engine combination makes its own decisions about task ordering and event-loop behavior. Concepts such as microtasks, nextTick callbacks, timers, and immediates are introduced to show how asynchronous work is organized, and the chapter demonstrates that subtle implementation and host differences can lead to surprising output or even runtime errors when code relies on behavior that is not standardized.
To explain these surprises, the chapter distinguishes among language-defined, implementation-defined, and host-defined behavior. Promises are part of the ECMAScript language and should behave consistently, while APIs like process.nextTick() and setImmediate() are Node.js-specific host features that vary across environments. The broader message is that developers need an owner’s-manual mindset: knowing not just how to write JavaScript, but how the language, engine, and runtime cooperate, especially when debugging bugs or performance issues in real applications.
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
Why does the same JavaScript code sometimes print different results in different runtimes?Different runtimes make different choices about scheduling and executing asynchronous work. JavaScript itself defines some behavior, but runtimes like Node.js, Deno, Bun, and browsers add their own event loop rules, task queues, and host APIs, which can change the observable output.What is the main point of the “When a hello isn’t hello” example?The example shows that identical-looking code can behave differently depending on the runtime and module system. It demonstrates that understanding only the surface syntax of JavaScript is not enough; you also need to understand how the runtime handles queues and scheduling.What output does the sample code produce in Node.js CommonJS?In Node.js using CommonJS, the code prints Hello. Node.js drains process.nextTick() before microtasks, then runs the timer and immediate phases in a way that produces that result.Why does the same code produce a different result in Node.js ESM?Running the same code as an ECMAScript module changes how Node.js schedules and drains queues. That alters the execution order, producing output like elHo followed by l instead of Hello.Why does Deno fail when running the original example?Deno does not provide setImmediate() in the global scope by default. The original code depends on that Node.js-specific API, so Deno throws a ReferenceError unless you import or enable Node compatibility features.Why does Bun print yet another different result?Bun uses its own runtime behavior and event loop scheduling choices. Even though it runs the same code, the ordering of microtasks, timers, and immediates differs enough to produce a different output.What is the difference between the JavaScript engine and the host runtime?The JavaScript engine parses, compiles, and executes JavaScript code. The host runtime embeds that engine and provides external capabilities like timers, networking, file system access, and event scheduling.What is an event loop?The event loop is the mechanism a runtime uses to schedule and process JavaScript work over time. It checks for pending events or tasks, runs the associated code one at a time, and keeps the application responsive or productive depending on the runtime.What are microtasks, nextTicks, and immediates?They are different queues used to schedule future work. Microtasks are used by promises and queueMicrotask(), nextTicks are Node.js-specific via process.nextTick(), and immediates are Node.js-specific via setImmediate().What does the book mean by language-defined, implementation-defined, and host-defined behavior?Language-defined behavior is specified by ECMAScript and should behave consistently everywhere. Implementation-defined behavior depends on the JavaScript engine, so runtimes using the same engine are often similar. Host-defined behavior comes from the runtime itself, so it may vary widely between Node.js, browsers, Deno, Bun, and others.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
JavaScript in Depth ebook for free
