Builtin naming alignment on js prefix

[guybedford]

I posted a summary of the builtin naming discussion on the ESM Integration at WebAssembly/esm-integration#118 (comment).

I think it would be good to ensure alignment with this wasm:js/... convention, and possibly even this proposal to align the previous proposals as well.

Currently we have the following builtin names defined by the string builtins proposal:

• wasm:js-strings
• wasm:text-encoder
• wasm:text-decoder

Instead of defining into wasm:text-encoding, it could be beneficial to rather combine with the existing wasm:text-encoder and wasm:text-decoder names, then rather alias these existing builtin names.

That is, to provide wasm:js/text-encoder as an alias for wasm:text-encoder and wasm:js/text-decoder as an alias for wasm:text-decoder, and then extend the new builtin names on the new alias instead.

Whether we want to also alias wasm:js/strings to wasm:js-strings in this proposal or via another means should also be considered for full alignment with the new naming convention.

[jakobkummerow]

Ultimately I don't care, but I'm curious: why the js/ part of js/text-encoder? The entirety of https://tc39.es/ecma262/ contains no mention of the word "TextEncoder" (nor "TextDecoder" for that matter).

[guybedford]

@eqrion initially posted the suggestion for JS embedder specific builtin prefixing based on wasm:string-constants being too general which justified the wasm:js/string-constants name. I think it would be good to try and capture the consideration here for other builtins being implemented, and it is worth having that wider discussion. I don't have a very clear sense of the distinction still myself other than the fact that JS embedder builtins would then be distinguished from non-JS-specific embedder builtins?

[eqrion]

Apologies for the long post here. We didn't systematically design a naming scheme for wasm js-string-builtins and so I'm trying to work through all the principles to make this future proof going forward.

wasm:text-encoder and wasm:text-decoder were considered in js-string-builtins but were deferred from the proposal. The only builtin set we have fully standardized is wasm:js-string.

I also agree with WebAssembly#118 that there is some consensus to standardize on the wasm:$namespace/$interface format (e.g. wasm:js/string) to avoid scheme proliferation and not use wasm-js for most builtins. It also has the nice property of being a URL.

But I don't believe that has been implemented anywhere yet, nor is there a plan for which proposal (if any) would add that. We'd have to have a one-time alias from wasm:js-string to wasm:js/string, and ideally going forward we'd use the new format for everything.

Ultimately I don't care, but I'm curious: why the js/ part of js/text-encoder? The entirety of https://tc39.es/ecma262/ contains no mention of the word "TextEncoder" (nor "TextDecoder" for that matter).

This touches on a similar issue that TC39 had with their builtin modules proposal (tc39/proposal-built-in-modules#66). What $namespace do you use for things?

Strings are obviously part of the core JS spec and language. Whereas the TextEncoder/TextDecoder are technically WHATWG/Web (but are also exposed on non-web platforms like Node). And sometimes interfaces move around between standards bodies (typed arrays were WebGL first before merging into the JS spec IIRC), so it's not clear you could have a web/ or whatwg/ namespace without introducing aliases someday.

I think we are potentially in a different situation than TC39 here. I think we could just define everything under the js namespace, because whether or not they're defined in the JS specification, they are defined in terms of JS language interfaces that are exposed on the host. This would be my preference.

That then leaves the question of what to use for the second part, the $interface. If possible, we should avoid creating our own interface names or tying them to individual specs (because the interfaces can move between specs).

I would suggest we use the property name exposed on the global for $interface. There are backwards compat requirements on that, so it's going to be the most stable name. It also matches what users know.

So for this proposal we'd have:

1. wasm:js/text-encoder
2. wasm:js/text-decoder

I suppose we could also revisit whether we should be snake casing these names (text-encoder vs TextEncoder). The individual builtin names have not been snake cased (e.g. fromCharCodeArray) so maybe we've been inconsistent.