Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose all window APIs as built-in ES modules #10636

Open
freshp86 opened this issue Sep 21, 2024 · 2 comments
Open

Expose all window APIs as built-in ES modules #10636

freshp86 opened this issue Sep 21, 2024 · 2 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest

Comments

@freshp86
Copy link

freshp86 commented Sep 21, 2024

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

@freshp86 freshp86 added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Sep 21, 2024
@freshp86 freshp86 changed the title Expose all window APIs as built-in ESM modules Expose all window APIs as built-in ES modules Sep 21, 2024
@Delapouite
Copy link

Related proposal from the TC39 perspective: https://github.com/tc39/proposal-built-in-modules

@nektro
Copy link

nektro commented Sep 23, 2024

Conversation in w3ctag/design-principles#426 feels relevant

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest
Development

No branches or pull requests

3 participants