JavaScript Global Object & Standard Global Functions

Advanced

The ECMAScript global object is the host-visible object associated with a Realm. The global environment is related to it, but the two are not interchangeable concepts. This lesson owns the remaining standard global access and global-function domain without re-teaching the constructors, collections, errors, numbers, strings, promises, or other built-ins already covered by their dedicated lessons.

Global object, global environment, and globalThis

A Realm has a global object and a Global Environment Record. The global environment supplies bindings for built-ins and top-level Script declarations, while the global object is an actual ECMAScript object. globalThis is the standard way to obtain the global this value without assuming a browser-specific name such as window.

?

Global bindings are not simply object properties

A Global Environment Record is composite. Script-level var/function declarations participate in the object-backed part, while let, const, and class declarations use the declarative part. This distinction matters when reasoning about whether a name is also a property of globalThis.

?

globalThis is portable; host APIs are not

ECMAScript defines globalThis, but hosts can add their own globals. Browser names such as window and self, Node-specific names such as process, and worker-specific globals are host concerns. A language lesson should use globalThis when it needs the global object without assuming a particular host.

?

eval: dynamic source evaluation

eval takes source text and evaluates it as ECMAScript code. A direct call to the intrinsic eval from the same syntactic context has special scope behavior; an indirect call evaluates in the global context instead. This lesson teaches the semantic distinction, not a recommendation to use dynamic evaluation.

?

eval and strict mode

Strictness affects eval. Strict eval code does not introduce bindings into the surrounding variable environment in the same way non-strict direct eval can. Dynamic source also crosses a security and tooling boundary, so ordinary application code should prefer explicit functions, modules, and data parsing when those express the intent.

?

isFinite performs numeric coercion

The global isFinite first converts its argument to a Number and then checks whether that Number is finite. This differs from Number.isFinite, which tests without the same implicit coercion. The distinction is often more important than the final boolean.

?

isNaN also coerces

The global isNaN converts its argument to Number and then tests for NaN. Number.isNaN does not perform that coercion. When the input type is already known to be Number, Number.isNaN is often the clearer predicate.

?

parseInt: radix matters

parseInt converts its input to a string, trims leading whitespace, and interprets a leading integer according to the supplied radix. Supplying the radix explicitly makes intent clear and prevents accidental dependence on prefix rules.

?

parseInt stops at the first invalid digit

parseInt does not require the entire string to be a valid integer representation. It parses the longest valid prefix for the selected radix and ignores the remaining characters. If no valid prefix exists, it returns NaN.

?

parseFloat parses a decimal prefix

parseFloat trims leading whitespace and parses the longest leading portion that forms a decimal numeric literal. It may therefore accept a numeric prefix while ignoring trailing characters. This is different from requiring an entire string to match a numeric format.

?

URI encoding: complete URI versus component

encodeURI and decodeURI treat a string as a complete URI and preserve characters that can serve as URI delimiters. encodeURIComponent and decodeURIComponent treat the string as an individual component and therefore encode those delimiter characters too.

?

Decode with the matching function

decodeURI reverses URI-level escapes while preserving URI delimiters, whereas decodeURIComponent decodes component-level escapes. Invalid escape sequences or malformed UTF-8 cause URIError rather than silently producing arbitrary text.

?

URI functions operate on strings

The URI functions convert their argument to a String before encoding or decoding. They are not general URL parsers, and the ECMAScript specification deliberately leaves broader URI and web-platform behavior to host APIs.

?

Malformed URI escapes are errors

URI decoding validates escape sequences and their UTF-8 representation. A malformed sequence is not simply left alone: the operation throws a URIError. Error ownership remains with the Errors lesson; this section focuses only on the URI functions that produce it.

?

Legacy escape and unescape

Annex B defines escape and unescape as additional legacy global properties. They are retained for web compatibility and are not the modern URI API. New code should use the standardized encodeURI/encodeURIComponent and matching decoders instead.

?

Global constructor ownership map

The global object also exposes constructor properties, but v338 does not re-teach their semantics. Object and Function belong to the object/function lessons; Array and collections belong to their collection lessons; Date and Temporal belong to time; Promise belongs to Promises; Proxy/Reflect, typed arrays, SharedArrayBuffer/Atomics, Symbol, RegExp, WeakRef, and error types already have dedicated owners. This lesson only teaches how the global surface relates to those owners.

?

Authoring rules for the global surface

Use globalThis when code genuinely needs the global object; do not assume browser-only names. Prefer explicit radix arguments with parseInt. Distinguish global isFinite/isNaN coercion from Number.isFinite/Number.isNaN. Choose URI encoding based on whether the input is a complete URI or a component. Avoid eval unless dynamic source evaluation is an explicit requirement, and treat escape/unescape as legacy compatibility features.