What Is JavaScript and Where Does It Run?

JavaScript is a high-level, dynamically typed programming language. Brendan Eich created it at Netscape in 1995, and Ecma International later turned it into a standard called ECMAScript. That standard is the language itself, and JavaScript is simply the most widely used version of it. The small differences between browsers are tracked in a public compatibility table, so you can always check which features are safe to use.

What makes this language unusual is where it runs. Because every browser ships with it, the same file can change a page, react to a click, and send data to a server without any build step and without installing anything extra. The same syntax also runs on servers through Node.js, Deno, and Bun. It runs inside mobile apps through React Native, at the edge of the network through services such as Cloudflare Workers, and even inside databases, because MongoDB queries are written in a dialect of JavaScript.

In real projects you meet it in three layers. The first layer is the presentation code that changes what the user sees on the screen. The second layer is the application logic that holds the rules of the business. The third layer is the transport code that moves data over HTTP. In an interview, the interviewer usually cares less about the history and more about whether you can pick the right runtime for a job, and whether you can write code that behaves in the same way in a browser tab and in a server process.

The smallest useful program is one call to the console object. You run it with node app.js on a server, and in a browser you either paste it into the DevTools console or load it from a script tag in your page.

console.log('Hello from JavaScript');

The console object writes to standard output on a server and to the developer console in a browser, and that is why it became the normal way to check a value while you work. It accepts several arguments and prints them separated by a space, and it shows objects with limited depth so that nested structures stay readable instead of collapsing into a wall of brackets.

Two cautions are worth raising in an interview. First, console.log is a diagnostic tool and not a logging system. Production code should use a structured logger that attaches timestamps, severity levels, and request identifiers, so that the output can be searched later. Second, anything you print in a browser tab is visible to the user, so never leave personal data, tokens, or secrets in it.

There is one more point that is worth making. This exact file runs in Node and in a browser without any change. That portability is the reason JavaScript is a good default for a script that has to work in a terminal, in a test runner, and on a page without any branching.

You look for a global that only one environment provides, and you use the typeof operator so that the check itself can never throw. A browser provides window and document. Node provides process. If neither one is there, then you are probably running inside a worker, an edge runtime, or some other sandbox.

const hasWindow = typeof window !== 'undefined';
const hasProcess = typeof process !== 'undefined';

console.log('browser:', hasWindow);
console.log('node:', hasProcess);

if (hasWindow) {
  console.log('environment: browser');
} else if (hasProcess) {
  console.log('environment: node');
} else {
  console.log('environment: other');
}

Checking the shape of each global one level at a time is deliberate. A bundler can put the word process into a browser build without giving it the same contents, so a careful check of each property stops a half-present global from crashing your detection. That is the difference between a check that is really safe and one that only looks safe.

A more durable approach for a library is to stop sniffing the environment altogether and to accept the abilities of the host as arguments instead. You can inject a clock or an HTTP client into your module that way. Detection is fine for a small script, but in a library that has to survive a browser, a bundler, a worker, and a test runner, checking for the ability you need is better than guessing the environment, because it states exactly what you require.

Expect a follow-up question about why typeof is used instead of writing the name directly. If you write window on a server, that line throws a ReferenceError before any condition can run at all.