domenic
commented
5 years ago On the web, I can state that we are not interested in separating by standards bodies or environments. Developers must not need to know whether setTimeout (or its future promise-based standard-library ilk) is defined by WHATWG, W3C, WICG, Khronos, or TC39; they must just be able to get it from "std:" (or whatever shared prefix).
We have faith in the ability of the multiple standards bodies that contribute to the platform to coordinate, as they have done with the global namespace, to ensure a harmonious experience for everyone. As @annevk notes, this has been a fruitful collaboration in the past, e.g. ArrayBuffers moving from web-specific (Khronos) to JS-language-level (TC39).
We are not OK with shifting the burden onto web developers to know the difference between groups, or the movement of specs between groups, in order to make our lives as standards developers slightly easier by allowing us to work in non-coordinated silos. This follows very directly from the priority of constituencies: "consider users over authors over implementors over specifiers over theoretical purity".
Whether Node.js wants to use the same policy as the web, or different, is of course up to them.
isaacs
littledan
styfle
Myself and several others at npm (a voting member) feel that we should be using the existing cowpath for scoped module syntax (
@std/foo) instead ofstd:fooor other such alternatives.While this would usually come down to a simple matter of taste, in this case, we have 254,091 scoped packages in the registry already using this syntax. That's more than most other package registries for other languages, as-is, and is a significant % of our ~950k packages on the main npm registry.
This syntax would also be beneficial because it allows an existing mechanism for polyfills that will work with all current and past versions of node, and can easily be made to work with the browser module system through this proposal and others specifying what non-
./specifiers are supposed to do to resolve.