Not convinced of use cases

[sffc]

Here are what I understand as the reasons why the champions feel built-in modules should exist:

1. Performance: Global objects increase code size and memory usage. Built-in modules give implementations more flexibility to perform optimizations.
2. Code health: You should think of built-in modules the same way they think of third-party modules.

On point 1, if I recall correctly, we have heard from browser engine implementors that they are able to lazy-load global objects and achieve good performance. It's already a solved problem. Engines will still need to ship this lazy-loading logic so long as globals continue to exist.

On point 2, I see that argument, but the proposal also brings downsides to code health (main issue: #58).

I also don't understand this: the README says, "The JavaScript language does not have a standard library", which is simply not true; Intl, Regex, Map, and Set are all examples of standard library.

Built-in modules are a big change to the ecosystem, and I am not convinced that the suggested use cases carry enough merit to justify the disruption.

[kaizhu256]

i would go further and argue that es-modules were a mistake.

sure js-rollups in browsers have issues, but they're all fairly manageable for product-developers and devops. es-modules, otoh, have caused product-developers nothing but endless grief, wasting our time firefighting bugs in unncessary tooling, instead of shipping ux-features.

[runarberg]

A nice example of point 2 is functions that are defined on globalThis:

import { setTimeout, setInterval } from "js:timers";

setTimeout(/* ... */);
setInterval(/* ... */);

This is equivalent to:

const { setTimout, setInterval } = globalThis;

But the former feels cleaner. Usage of globalThis has been—to word it politely—a bit bumpy, linters, lint rules, and transpilers are sometimes still using the global name which appeared before the spec was finalized, meaning that—as developers—it is still kind of hard to figure out what is the name of the global object. With this proposal in place we could conceive a new lint rule no-global-object which forces us to always import the methods and namespaces we plan to use from the global object while we never have to think about what the name of the global object is.

[devsnek]

any engine with these modules is guaranteed to have globalThis already, so no need to worry about which global name to use.

[runarberg]

@devsnek The problem is that we developers don’t always write directly for the engines that our users are using, so if our transpilers, linters, or lint rules are not up to date (which—sorry to say—is the case with globalThis).

[devsnek]

there are also plenty of globalThis polyfills

[codehag]

I would like to echo some of the concerns of @sffc here. I understood a similar motivation based on the explainer.

I would also like to add some of the ones presented in the slides, including namespace collisions (which are a sore point for the committee). The other goals feel like they are not so significant that it is worth splitting into two locations: global and the builtin modules.

One of the reasons that I would like to raise, that would show a significant enough motivation, was that this would allow Wasm to import DOM related APIs. I don't know if this is still important (cc @lars-t-hansen). At present, the motivation without this does not seem strong enough to outweigh the potential issues. I would be interested to see if there are more fundamental benefits that we could find here before saying this is a problem space that needs solving. cc'ing @annevk for visibility.