Closed legendecas closed 9 months ago
If you look at https://developer.mozilla.org/en-US/docs/Web/API/Navigator, there are many more things available on navigator
than just primitive strings and numbers. There are full-blown APIs like navigator.clipboard
and navigator.share()
and so on. Most of these aren’t obviously useful to server-side runtimes but I can imagine some of them might actually be; like a command-line tool might potentially do something useful with the clipboard, or pop up the native OS’ Share dialog.
These methods are not present at the WorkerNavigator, which is the navigator object in web worker contexts. The WorkerNavigator
is a subset of the main context Navigator
, which makes more sense in a headless environment.
So I would avoid expanding the common-minimum-api to be the full set of Navigator
, but limit it to be a subset of WorkerNavigator
.
So I would avoid expanding the common-minimum-api to be the full set of
Navigator
, but limit it to be a subset ofWorkerNavigator
.
Oh sure, I wasn’t suggesting we include all those APIs in the common minimum. Just that we should perhaps rename this from “attributes” to some thing like “Navigator APIs” because some of the keys on navigator
aren’t primitives.
Sure, thanks for the suggestion!
I think there's enough consensus among the runtimes that we should add at least some of these. I will say that workers is likely unable to ever add navigator.hardwareConcurrency
(we have no need given the way we virtualize and time-share CPU), and we don't really have a strong case for navigator.platform
, navigator.language
, and navigator.languages
, and navigator.onLine
doesn't really make sense for the always-on edge environment... but if a particular set of attributes are implemented by at least two of the runtimes then we can make an argument to include them.
if a particular set of attributes are implemented by at least two of the runtimes then we can make an argument to include them.
Node, Deno and Bun all implement the following (reference 1, reference 2):
navigator.hardwareConcurrency
navigator.platform
navigator.userAgent
Node and Deno additionally implement:
navigator.language
navigator.languages
navigator.userAgent
is already in the minimum common API, which makes sense; its very purpose is to identify the current runtime, which seems like an important thing to have a cross-platform way to do.
Likewise navigator.platform
, for determining the current OS and chipset, is another thing that seems really useful to have a cross-platform API for.
I think navigator.hardwareConcurrency
‘s primary value is in letting you know how many cores are available, which would influence how many threads get spawned (?). I can understand if this isn’t relevant to workerd
, or could it just always return 1 for this? But seeing as we have a cross-platform API for worker threads, it feels logical to have a cross-platform way to know how many threads should be spawned.
Note that Deno Deploy supports navigator.hardwareConcurrency
, despite not supporting workers, and it seems to always return 1.
Closed with https://github.com/wintercg/navigator-registry.
Most of these aren’t obviously useful to server-side runtimes but I can imagine some of them might actually be; like a command-line tool might potentially do something useful with the clipboard, or pop up the native OS’ Share dialog.
Definitely. Just running in the cloud, these aren't useful (or would be strange to use), but many runtimes, at least the ones most seem to refer to, are equally at home running locally for tooling.
I don't think there is an abundance of people using edge-runtime or cloudflare workers to run cli tools, but Bun and Deno do get some use, and of course, Deno.
And then there is also doing a runtime emulation of browser environments. Though, I think that case could more likely be simply polyfilled.
I will say that workers is likely unable to ever add
navigator.hardwareConcurrency
(we have no need given the way we virtualize and time-share CPU), and we don't really have a strong case fornavigator.platform
,navigator.language
, andnavigator.languages
, andnavigator.onLine
doesn't really make sense for the always-on edge environment.
Would not simply providing them with "dummy" results be valuable? hardwareConcurrency
just always returns 1
, etc.
Or would it be better to not have them at all to make feature detection easier?
I guess I'd be torn between whether easy feature detection is better than being interface compliant (even if functionally incorrect)
There are lots of APIs defined on the Navigator object. For now, the common minimum API merely defines
navigator.userAgent
as part of the common APIs that WinterCG runtimes are interested in implementing.However, it is being proposed to add more properties to
Navigator
in Node.js for usefulness (e.g.Navigator.hardwareConcurrency
) and legacy compatibility (e.g. constantNavigator.appVersion
version)Current implementation status:
Navigator.userAgent
Navigator.hardwareConcurrency
Navigator.platform
Navigator.language
Navigator.languages
Navigator.onLine
Navigator.userAgent
andNavigator.platform
)I believe the common APIs of
Navigator
should be extended to include attributes that were shipped in more than two runtimes. Also, if there are strong push-backs on adding the above APIs to the common minimum API, we should be wary of shipping them to reduce the gaps between the runtimes.