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

On Aug 18, 2013 7:20 AM, "David Bruant" <bruant.d@gmail.com> wrote:
>
> 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 enough.
>
>
>> 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
property?
>
> David
>

I am a big advocate of us figuring this out.  HTML now has a forward compat
strategy for the author space in the form of custom tags (after what may
have been one of the longest running debates ever, they contain a dash and
an ability to express what they extend) and data-* attributes.  CSS'
forward compat grammar has always allowed vendor prefix in all the right
places and author works just as well there - and conveniently vendors are
going to stop using so that works out even better... But in DOM and
JavaScript I feel like we are lacking such a plan that can be communicated.

Our group (next-web) is as active offlist as on atm - I feel like we have
good abilities to help spread a message if we can get something there.