Browser, Node and Beyond

Node is built on the V8 engine, and it adds a set of globals that only make sense on a machine with a filesystem, a process list, and a network connection. The most important ones are process, which describes the running program, Buffer, which is used for raw bytes, and global, which is the name Node gives to the global object. Node also adds setImmediate, which schedules work to run after the current round of the event loop, and it gives you the standard library modules through require rather than through more globals.

console.log(typeof process);       // object
console.log(typeof Buffer);        // function
console.log(typeof global);        // object
console.log(typeof setImmediate);  // function

console.log(process.platform);    // linux, win32, darwin
console.log(process.cwd());        // the folder the script was started from
console.log(process.pid);         // the process id

The browser has its own set of extras instead. It provides window, document, navigator, location, history, localStorage, and the fetch APIs. Neither environment is a bigger version of the other, and that is exactly why portable code should not depend on either one.

One detail is worth getting right. In Node, global is the global object, and globalThis is the newer standard name that works in both environments. If your code has to reach the global scope, prefer globalThis, because it behaves the same in a browser, in Node, and inside a web worker.

There is one more practical point. The fact that Node can read files and open network connections is a security decision and not a technical one. Browser code runs inside a sandbox that deliberately forbids direct access to the machine, which is why a web page has to ask the user to pick a file instead of simply opening one.

The node:fs module gives you both a synchronous and an asynchronous way to work with files. Keeping the example synchronous makes the order of the output obvious, and that is what you want while you are showing it in an interview.

const fs = require('node:fs');

fs.writeFileSync('notes.txt', 'first line\nsecond line\n');

const lines = fs.readFileSync('notes.txt', 'utf8').split('\n');
console.log(lines[0]);

Two details are worth calling out. The utf8 argument matters, because without it you get raw bytes instead of text, and printing raw bytes shows numbers rather than words. And splitting the text on the newline character before you read the first item gives you the first line, which is a pattern that you will use again and again whenever you parse text.

Now the important contrast for the interview. A browser page cannot do this. There is no equivalent of reading an arbitrary path, because the page is not trusted to touch the disk of the user. Browsers offer the File API instead, where the user explicitly selects a file and the page receives a handle to it. That difference is the whole reason the same language needs two different sets of platform APIs.

If a reviewer asks about performance, mention that the synchronous calls block the event loop. That is fine in a short script, but it is the wrong choice inside a server that is handling many requests. There you would use the promise-based or the stream-based versions instead.

The difference comes down to how the runtime evaluates a file. A browser loads a classic script and evaluates it as a piece of the global scope, so a top-level var becomes a property of the global object and a top-level function becomes a global function that you can call from the console. A Node file is always treated as a module, so the runtime wraps it inside a function and gives it its own scope.

// Node wraps this file in a function, so nothing here leaks out.
var leaked = 'module scope';
const alsoLocal = 'module scope';

console.log(typeof globalThis.leaked); // undefined - not on the global object
console.log(typeof global.leaked);     // undefined
console.log(globalThis === global);     // true in Node
console.log(typeof require);           // function - Node only
console.log(typeof module);            // object - Node only

That wrapper is also where Node puts module, exports, require, and __filename. You never see the wrapper itself, but it explains why two files can both declare a variable called currentUser without colliding, while two classic scripts on the same page would fight over one global name.

Browsers have caught up through the module script type, which is the standard module system of the language and behaves much more like Node. It has its own scope, it is deferred by default, it is always strict, and it supports import and export. The rule of thumb to give an interviewer is simple. Any file with an import or an export statement is a module and gets its own scope. A plain script without them stays in the global scope, unless the type attribute says otherwise.

There is a useful side effect of that difference. A browser script that is loaded twice with the classic type will declare its globals twice, and it will throw when it finds two let or const declarations with the same name. Modules are cached and evaluated only once, so loading them twice does no harm at all.