Non-agression pact for the JS runtime namespace territory

Hi,

[I'm not entirely sure "non-agression pact" is the best expression. What 
I mean is "let's decide on a border and respect one another's border"]

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.

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.

Before my initial proposal, I'd like to address some points:
* A first limitation is that not all devs will get the memo. However, a 
good thing about an agreement between browsers and webdevs is that 
tooling can inform that the agreement has been violated and recommend 
what to do to respect the agreement.
Also, people aware and caring of the agreement can have a reference 
point on what to do and what not to do to share with an open source 
library they'd have noticed not respecting the agreement. (For whatever 
reason, I can already imagine Rick Waldron or Dominic Denicola filing 
such issues on Github :-) )
* This proposal also doesn't really help with existing deployed code 
(browser devtools integration may raise alerts and trigger fixes though)
* 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.

I think technical and language-based solutions have been explored enough 
and shown to fail, so I believe an human-agreement-based solution 
(backed by static+dynamic tooling) is worth a try.


The proposal I'm making here is in part documenting existing practice 
and in part trying to introduce new rules.

Initial Proposal (future-facing, but assuming backward compat, obviously):
* The global object is free for everyone (spec or webdevs) to write on 
it. Creating a global property should never fail for JS code.
Among other things, this is supposed to prevent new APIs to define 
immutable global properties [2].
This rules allows for instance jQuery to define "$" and "jQuery" global 
symbols without fearing that a spec may one day define immutable 
properties with these names.
WebIDL tests may be able to enforce such a property. That may become a 
hard requirement for a spec to move to Last Call state for instance.

* 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 (beyond the ones that may already exists 
for backward-compat reasons of course)
WebIDL tests may be able to enforce such a property. That may become a 
hard requirement for a spec to move to Last Call state for instance.

* Web developers commit to never extend a built-in unless the property 
name starts with '_'.
This can be enforced by developers themselves via static tooling and 
human review or via browser devtools that can emit a warning in a 
webconsole explaining that for the good of the long-term of their 
application, web devs should change their code.


This is of course an initial proposal and only the beginning of a 
discussion.

David

[1] https://mail.mozilla.org/pipermail/es-discuss/2013-July/032228.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0224.html

Received on Saturday, 17 August 2013 14:08:29 UTC