Update: I must admit my fault in over-generalizing my conclusions, that said, my position regarding import maps being the solution for builtins where every library (assuming a world without the need of bundlers per intent) will be baked with some
builtin-polyfillmapping following some convention — that redundancy does not belong in the module map that is used to bootstrap all the things.
So not sure if you guys saw this: https://developers.google.com/web/updates/2019/03/kv-storage
I am posting this cautiously here because while dropping scoped access to globals is a premise I am working off towards the realization of safe modules, doing it wrong is going to make this backfire!
While you read the kv-storage post, make sure you read the portion addressing import maps and then read import maps. How much thought would it take for an author blogging in such a venue to come to the realization that import maps will most likely not support “std:” or standard scheme prefixes — which is may be not explicitly stated yet — because import maps cannot ever be allowed to shadow select URLs (ie inject code with an otherwise trusted certificate of authority). So, let’s say I am wrong, did they even consider testing their claim for polyfilling in other browsers.
While I am not ready to defend dynamic namespaces, it is exactly these kinds of proposal theatrics that make people demand features before they are thought out and while they are too untenable and impossible to properly test their validity as experimental candidates on more critical aspects like security and future-adequacy.
I wanted to see what everyone else thinks about all this while I slowly work to present you with a more complete and adequately comprehensive way to do away with the unsecure aspects of
global scope in code that does not need it — ie and allow legacy to be legacy (mostly).