whatwg
Expose all window APIs as built-in ES modules
What problem are you trying to solve?
The window object is the entry point to many (hundreds?) web APIs. For example window.print(), window.location, window.navigator, window.indexedDB, new window.AudioConext() and many more, which is quite messy and suboptimal. Figuring out which APIs are used by a certain piece of code/document requires
- searching the body of the code for humans (looking for
window.<foo>references) - grepping/regexing the entire code for code analysis tools
- evaluating the code for Javascript engines
Now that ES modules are widely available and fully supported by all major browsers, it seems reasonable to provide an option to import all built-in browser APIs from built-in ES modules using some special URLs, for example
import {print} from 'browser:print';
import {location} from 'browser:location';
import {navigator} from 'browser:navigator';
import {AudioContext} from 'browser:audio-context';
print();
console.log(location.href);
console.log(navigator.userAgent);
const ac = new AudioContext();
which is similar to the NodeJS approach of importing built-in modules, as follows
import {open} from 'node:fs/promises';
In addition, there could be something similar to "use strict" offered to only expose such APIs though ES module imports, and completely remove them from the window object.
This would make it easier to tell what are the API dependencies of a page for both humans and tools, and possibly even make it easier for JS engines to omit initializing various backend pieces if a page is not using them (which could be determined just by parsing ES non-dynamic imports before evaluating the rest of the code). It would also allow using all the other ES module features, like using as to create aliases within the current module, and more generally it would bring built-in web APIs more up to par with modern JS development practices (already followed by many external libraries which are offered as JS modules).
What solutions exist today?
Not aware of any solutions or similar proposals, but it is possible that I might have missed them.
How would you solve it?
No response
Anything else?
No response
Related proposal from the TC39 perspective: https://github.com/tc39/proposal-built-in-modules
Conversation in https://github.com/w3ctag/design-principles/issues/426 feels relevant
