W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: Non-agression pact for the JS runtime namespace territory

From: David Bruant <bruant.d@gmail.com>
Date: Sun, 18 Aug 2013 13:20:21 +0200
Message-ID: <5210ADF5.3030000@gmail.com>
To: François REMY <francois.remy.dev@outlook.com>
CC: public-script-coord@w3.org, public-nextweb@w3.org
Le 18/08/2013 05:54, François REMY a écrit :
> (cced the Extensible Web CG since prefixing issues have been discussed extensively there)
> ± So, recently, there have been some collisions between methods added by a
> ± library and ES6 planned Array#find, maybe endangering the addition of
> ± Array#find to the platform. The details are unimportant; what is important is
> ± that that'll happen again.
> ±
> ± I'm coming as a (totally illegitimate) web developer community
> ± representative to ask if we can agree on some rules that would both enable
> ± developers to create libraries and extend built-ins (because
> ± myArray.newMethod() or "some string".whatever() or
> ± document.querySelectorAll(s).map are convenient) while not preventing
> ± future growth of platform APIs.
> I agree with you on the premises.
> ± The reason is that currently, each library is trying over and over to solve the
> ± namespacing problem. Some do fine. Others fail. We need a platform-wide
> ± principle. We need commitment from web browsers and specs that some
> ± parts of the namespaces are free for library authors to use freely.
> That may sometimes not work. The issue that it solves is that some modern code will never fail on a website because the native function he expects has been replaced by some other one. The issue it doesn't solve is that two libraries could want to use the same function name with different purposes/implementations.
Agreed. But libraries competing for the namespace is not a problem the 
problem being addressed here. I believe it's a problem that webdevs need 
to solve among themselves and doesn't require involvement of the web 
browsers. (I wasn't aware of the public-nextweb mailing-list and it 
might just be the right place)
I'm happy if an idea that solves both "webdev VS browsers" and "webdev 
VS webdev" emerges, but I can't think of any for now.

Note that for libraries and user code, independent properties or 
Array.prototype, etc. can be made immutable preventing unexpected 
changes. That can be enough at dev time to notice any conflict between 2 
libraries. And I can't think of a reasonable use case where conflicts 
between 2 libraries would be useful.
Anyway, I feel "webdev VS webdev" can be solved independently.

> ± * unique strings [1] (eventually unique symbols) could be used to guarantee
> ± avoiding collisions. The simplest form of cooperation between a library and
> ± client code I have found is at
> ± https://gist.github.com/DavidBruant/6256883 and I'm not sure it's
> ± satisfactory I believe that the forced bracket notation in client code and the
> ± sharing through globals (for things that are supposed to be already reachable
> ± from the global!) is the reason why web devs haven't come up with this
> ± solution themselves.
> The main issue there is the global variables. We only partly solve the issue because we've to expose our key-related stuff, and we've to expose it in a way that's not particularly elegant.
I think we agree. My main point was that although unique 
strings/symbols, although designed for that use case aren't practical 

> However, with the raise of modules, exporting keys will become much easier. Any code can simply import a module, and the module will bring with him the key names. The user code can safely choose to use direct or namespaced import if he believes the import could conflict with another library.
Sure, but it doesn't change the bracket syntax (and "key-model" you 
address below) and need for import/destructuing which is always one more 
step than if the library changed Array.prototype directly.

> The only thing that sucks right now is that it's hard to provide a good intellisense (autocompletion) for those keys because they do not have a canonical name. Maybe we should define a way for unique strings to be exposed properly (alternatively we can ask the IDE to be smart an guess the keynames currently accessible by walking through imported modules).
> The second thing I dislike terribly is that the current key-model breaks your mental model, because you've to care whether you are using a "normal" property (in which case you have to type a dot) or a "custom" property (in which case you have to type a bracket).
> I think the language would be in a much better shape to deal with the naming issues if it did support "obj.[key]" as an alias to "obj[key]". Some languages like F# allow that and I find it very convenient. It helps me get straight to the point. SweetJS, TypeScript or my IDE could help me with that during the transition, but this will only be implemented in a sufficient amount of IDEs if ecmascript adds it to its future version roadmap.
 From all of that, it seems that we agree unique strings/symbols aren't 
as practical for what they're intended as we wished.

> ± * The global object is free for everyone (spec or webdevs) to write on it.
> ± Creating a global property should never fail for JS code.
> Defintely agree with you, but again this only solve part of the problem. If I library overwrite some native function, you can't use it on your website after that (and some other scripts may do the mistake to confuse them).
I was only referring to the global object and its properties.
But to answer your point, it's worse than what you describe. My proposal 
does not solve the problem. I touched on that with the section starting 
with "not all devs will get the memo".

Even if (some!) web devs and web browsers come to an agreement, some 
webdevs won't be aware. The proposal here does not aim at solving the 
problem completely, but move towards a solution.
Specifically, if we can ever have at least both Chrome and Firefox 
devtools showing a warning anytime devs don't do something agreed upon 
here, that'd be a good step forward.

> ± * Web browsers commit to never define methods or attributes (using
> ± WebIDL terminology, but applies equally to the ECMA 262 spec) that starts
> ± with "_" to built-ins
> It should clearly have been the case forever. I will never hate __proto__ enough given what it merits...
> ± * Web developers commit to never extend a built-in unless the property
> ± name starts with '_'.
> I cannot agree on that. Firstly, using an underscore is ugly.
Bikeshed :-) I personally don't care about the prefix (or suffix or 
whatever) being chosen. What I care about in my proposal is the 
principle of part of the namespace belonging to browsers/specs and part 
of the namespace belonging to webdevs

> Secondly, it doesn’t solve cross-library prefixing.
As I said above, this isn't the problem being solved here. Webdevs need 
to figure this one out without the involvement of browsers.

> Anf finally, extending may have multiple meanings here, depending on which you may or may not want to allow such extensions.
> If an extension is a *true* polyfill, in the sense it polyfills a relatively stable spec that has been shipping in at least a browser and that it does his job correctly, I've no issue reusing the real name for the polyfill.
Agreed. Polyfills of course can go unprefixed. Polyfills are a very 
specific sort of library that are aimed explicitly at adding things in 
the "browser namespace" and follow the specs as closely as possible.

> If the extension is a prollyfill (ie: "I wish browsers had it") then they should definitely use a unique string/symbol. There's simply no way a speculative polyfill can deal with a browser or another library shipping an implementation of his stuff, so we must be sure conflicts simply do not happen.
For a prollyfill, what's the benefit of a unique string over a prefixed 

Received on Sunday, 18 August 2013 11:20:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC