I’m hoping to order a bunch of JavaScript APIs by usage, as a way to understand which of the APIs might be more/less important.
Is there a recommended way to translate JavaScript API names (e.g. window.navigator.userAgent aka Navigator.userAgent) into a feature name as used by HTTP archive and chromestatus.com (e.g. NavigatorUserAgent)?
An approximation might be to remove the window prefix and adjust to camelCase while removing the later .'s (e.g. window.navigator.userAgent → .navigator.userAgent → NavigatorUserAgent ). But I’m guessing an approach like that would be quite error prone.
I attempted to read through the HTTP Archive GitHub repositories to understand how it’s decided that a feature like NavigatorUserAgent feature was active for a page. I figured from there, I might be able to see which feature name translates to which API. It seems to be that the HAR files collected have a bunch of numeric codes that denote which features were active, but I couldn’t see where those codes were set - perhaps that’s a part of Chromium?
The feature names are listed in web_features.mojom in the Chromium source.
Usage of features is recorded in the Chromium source with calls like UseCounter::Count(current_execution_context, WebFeature::kNavigatorUserAgent); and entries in IDL interface files like MeasureAs=SharedStorageAPI_Set_Method. Probably other ways as well.
I’m not sure that there’s an obvious way to translate feature name to API name reliably, other than going through the list of > 4k features, and coming up with a feature name → APi name mapping by checking when each is called.
I don’t think there’s a perfect solution here, but in case someone else is wondering, here’s what I ended up doing:
I iterated through each entry in the feature popularity data and created two lookups:
feature name → popularity
simplified/normalised feature name → feature names
To simplify the feature names I converted to lower case, stripped strings like _attributegetter, _attributesetter, _method, _constructor, insecureoriginiframe, secureoriginiframe, crossoriginiframe, crosssiteiframe, prototype, _, prefixes like obsolete_ + v8 and suffixes like api.
Note: Any simplified name could match multiple feature names.
When looking up an API name, I would first undertake a similar process to simplify/normalise the API name. But here I come up with several possible simplified API names to try looking up. (That’s important since features are not named consistently, but by using the lookup the search is fast.)
Some API name transformations I do every time, e.g. stripping . characters and lowercasing.
Some transformations only have a chance of helping, so I add them to the list of possibilities. For example converting , xrsession → xr, useragentdata → uadata, notification.notification → notification, navigator.canshare → navigator.webshare.canshare, naviagator.* → *
From that, I would often have an array of possible feature names, can look up the corresponding popularities and return the list.
I found that the matches generally look right, but there’s quite often no match. In some cases, the popularities returned should probably be summed, but in other cases it seems better to return the highest of the returned popularities.
I think having a proper list of feature names → api names in the future would be really helpful, to avoid this guesswork!
