<p>In our front-end developer course at Algebra, we are being taught there are three different types of objects in JavaScript:</p>
<ol>
<li>Native objects - those that are defined by JavaScript itself, such as <code>Date</code>, <code>Math</code>, and so on.</li>
<li>Host objects - those that are provided by the environment that JavaScript is running in. In the case of browsers, it is <code>window</code> and <code>document</code>.</li>
<li>User-defined objects.</li>
</ol>
<p>Now, I am not sure where the WebAssembly object (through which WebAssembly and JavaScript communicate) would fit. Would it be a native object? As far as I know, it's not defined by the ECMAScript standard, so no. Would it be a host object? Then it wouldn't be available in both NodeJS and browsers, right? And it's obviously not user-defined.</p>

<javascript><webassembly>
Is `WebAssembly` (the object through which WebAssembly and JavaScript programs communicate) considered to be a host object or a native object?
CC BY-SA 4.0
2024-12-14T07:02:58.937Z
The ECMAScript standard hasn't included the concept of "host objects" for a decade, since ES6, and before the WebAssembly object was specified, so I think there's not a meaningful answer to this in specification terms. Are you looking for a specification-lawyer reading of how this *would have been* categorised under the 2009 ES5 definition, using the terms you've given, or a contemporary classification in terms of the more recent standards?
Michael Homer
CC BY-SA 4.0
2024-12-14T07:25:35.953Z
@MichaelHomer I'd be more interested in a contemporary classification using the more recent standards.
FlatAssembler
<p>The last version of ECMAScript that included &quot;host object&quot; as a defined category was ES5.1, the 2009 specification, and ES6 was released prior to WebAssembly, so there isn't really a &quot;true&quot; answer to this. In part, I believe this was because the two-category distinction was not useful, and a much finer gradation came in that defined object semantics in terms of specific operations, and a separate axis describes where the object comes from.</p>
<p>However, in terms of the ES5.1 specification, <a href="https://262.ecma-international.org/5.1/#sec-4.3.8" rel="nofollow noreferrer">&quot;host object&quot;</a> is defined as</p>
<blockquote>
<p>object supplied by the host environment to complete the execution environment of ECMAScript</p>
<p>NOTE Any object that is not native is a host object.</p>
</blockquote>
<p>Note that user-defined objects would generally be native objects as well: a native object is one whose behaviour is defined by the ECMAScript specification, including through the object-construction semantics. The ES3 definitions of these terms are similar, but formatted differently. Under the ES3 &amp; ES5 definition, anything injected from outside the specification itself will inherently be a host object, but the specification encourages these to behave observably like native objects. On that level, the WebAssembly object would presumably be a host object, but it's not very meaningful to classify it that way.</p>
<hr />
<p>Under the current 2024 specification, <code>WebAssembly</code> would be a <a href="https://262.ecma-international.org/#host" rel="nofollow noreferrer"><em>host-defined</em></a>, <a href="https://262.ecma-international.org/#sec-ordinary-object" rel="nofollow noreferrer">ordinary object</a>:</p>
<blockquote>
<p>facilities that are host-defined are often further defined in external specifications.</p>
</blockquote>
<blockquote>
<p><strong>ordinary object</strong>: object that has the default behaviour for the essential internal methods that must be supported by all objects</p>
</blockquote>
<p>There is no longer a special case in <code>typeof</code> that allowed host objects to produce a different type description, so any host-provided object must be identified as &quot;object&quot;, and the semantics of call, property access, and so on are all individually defined. An ordinary object complies with all of the default implementations of those operations, regardless of where it came from, and whether it is host-defined or not cannot be distinguished within the code. The specification refers to all of these operations using names like <em><code>[[Get]]</code></em>, and for ordinary objects they are defined <a href="https://262.ecma-international.org/#sec-ordinary-object-internal-methods-and-internal-slots" rel="nofollow noreferrer">in Section 10.1</a>; these are the &quot;normal&quot; JavaScript semantics we are used to on <code>{ ... }</code> objects, and only if something unusual needs to happen are they overridden. Those &quot;unusual&quot; things are not necessarily uncommon: <a href="https://262.ecma-international.org/#sec-array-exotic-objects" rel="nofollow noreferrer">arrays, with their magical indexing behaviours</a>, are <a href="https://262.ecma-international.org/#exotic-object" rel="nofollow noreferrer"><em>exotic</em> objects</a>, as are strings and proxies.</p>
<p>The <em>name</em> <code>WebAssembly</code> is a <a href="https://262.ecma-international.org/#sec-global-object" rel="nofollow noreferrer">host-defined name on the global object</a> which refers to that ordinary, host-defined object. It is in the same category as &quot;document&quot;, for example, because it is defined by an external standard but otherwise normal in behaviour. Other objects produced by the WebAssembly methods may be exotic objects, with non-default behaviours. This is now a distinct axis from being host-defined, unlike in the specifications of a decade-plus ago.</p>
<hr />
<p>You also ask</p>
<blockquote>
<p>Would it be a host object? Then it wouldn't be available in both NodeJS and browsers, right?</p>
</blockquote>
<p>Note that there is nothing to stop multiple hosts or implementations providing similar objects, methods, or bindings, or following similar external standards. There are several implementations of the language, and it's convenient to allow as much code as possible to run across any given one of them. You aren't guaranteed to find them there just because it's JavaScript, but the implementation can choose to tell you they'll be there.</p>
<p>In the case of NodeJS, sometimes these bindings come quite a long time after they appear in web browsers, and there's nothing compelling them to be included, but there are many instances of functionality defined outside of ECMAScript itself that is included. For example, <code>setTimeout</code> has long been present, but that's just a library function, not a mandated element of the global object — it's there because people want to use it there as well, and using the traditional name from the browser and DOM.</p>

CC BY-SA 4.0
2024-12-14T08:46:11.557Z
2024-12-14T08:46:11.557Z
Michael Homer
# Is `WebAssembly` (the object through which WebAssembly and JavaScript programs communicate) considered to be a host object or a native object?
Posted by: username_0 on 2024-12-14
In our front-end developer course at Algebra, we are being taught there are three different types of objects in JavaScript:

1. Native objects - those that are defined by JavaScript itself, such as `Date`, `Math`, and so on.
2. Host objects - those that are provided by the environment that JavaScript is running in. In the case of browsers, it is `window` and `document`.
3. User-defined objects.

Now, I am not sure where the WebAssembly object (through which WebAssembly and JavaScript communicate) would fit. Would it be a native object? As far as I know, it's not defined by the ECMAScript standard, so no. Would it be a host object? Then it wouldn't be available in both NodeJS and browsers, right? And it's obviously not user-defined.
**Tags:** javascript webassembly
> **Comments:**
> **username_1**: The ECMAScript standard hasn't included the concept of "host objects" for a decade, since ES6, and before the WebAssembly object was specified, so I think there's not a meaningful answer to this in specification terms. Are you looking for a specification-lawyer reading of how this *would have been* categorised under the 2009 ES5 definition, using the terms you've given, or a contemporary classification in terms of the more recent standards?  
> **username_0**: @MichaelHomer I'd be more interested in a contemporary classification using the more recent standards.  
---
## 1 answers
### Answer by username_1 on 2024-12-14. Score: 2 | Accepted answer
The last version of ECMAScript that included "host object" as a defined category was ES5.1, the 2009 specification, and ES6 was released prior to WebAssembly, so there isn't really a "true" answer to this. In part, I believe this was because the two-category distinction was not useful, and a much finer gradation came in that defined object semantics in terms of specific operations, and a separate axis describes where the object comes from.

However, in terms of the ES5.1 specification, ["host object"](https://262.ecma-international.org/5.1/#sec-4.3.8) is defined as

> object supplied by the host environment to complete the execution environment of ECMAScript
>
> NOTE Any object that is not native is a host object.

Note that user-defined objects would generally be native objects as well: a native object is one whose behaviour is defined by the ECMAScript specification, including through the object-construction semantics. The ES3 definitions of these terms are similar, but formatted differently. Under the ES3 & ES5 definition, anything injected from outside the specification itself will inherently be a host object, but the specification encourages these to behave observably like native objects. On that level, the WebAssembly object would presumably be a host object, but it's not very meaningful to classify it that way.

---

Under the current 2024 specification, `WebAssembly` would be a [*host-defined*](https://262.ecma-international.org/#host), [ordinary object](https://262.ecma-international.org/#sec-ordinary-object):

> facilities that are host-defined are often further defined in external specifications.

> **ordinary object**: object that has the default behaviour for the essential internal methods that must be supported by all objects

There is no longer a special case in `typeof` that allowed host objects to produce a different type description, so any host-provided object must be identified as "object", and the semantics of call, property access, and so on are all individually defined. An ordinary object complies with all of the default implementations of those operations, regardless of where it came from, and whether it is host-defined or not cannot be distinguished within the code. The specification refers to all of these operations using names like *`[[Get]]`*, and for ordinary objects they are defined [in Section 10.1](https://262.ecma-international.org/#sec-ordinary-object-internal-methods-and-internal-slots); these are the "normal" JavaScript semantics we are used to on `{ ... }` objects, and only if something unusual needs to happen are they overridden. Those "unusual" things are not necessarily uncommon: [arrays, with their magical indexing behaviours](https://262.ecma-international.org/#sec-array-exotic-objects), are [*exotic* objects](https://262.ecma-international.org/#exotic-object), as are strings and proxies.

The *name* `WebAssembly` is a [host-defined name on the global object](https://262.ecma-international.org/#sec-global-object) which refers to that ordinary, host-defined object. It is in the same category as "document", for example, because it is defined by an external standard but otherwise normal in behaviour. Other objects produced by the WebAssembly methods may be exotic objects, with non-default behaviours. This is now a distinct axis from being host-defined, unlike in the specifications of a decade-plus ago.

---

You also ask

> Would it be a host object? Then it wouldn't be available in both NodeJS and browsers, right?

Note that there is nothing to stop multiple hosts or implementations providing similar objects, methods, or bindings, or following similar external standards. There are several implementations of the language, and it's convenient to allow as much code as possible to run across any given one of them. You aren't guaranteed to find them there just because it's JavaScript, but the implementation can choose to tell you they'll be there.

In the case of NodeJS, sometimes these bindings come quite a long time after they appear in web browsers, and there's nothing compelling them to be included, but there are many instances of functionality defined outside of ECMAScript itself that is included. For example, `setTimeout` has long been present, but that's just a library function, not a mandated element of the global object — it's there because people want to use it there as well, and using the traditional name from the browser and DOM.
---
