May 24-26 rough meeting notes

Brendan Eich brendan at mozilla.com
Mon May 30 14:50:08 PDT 2011


On May 30, 2011, at 1:54 AM, Thaddee Tyl wrote:

> On Mon, May 30, 2011 at 6:55 AM, Brendan Eich <brendan at mozilla.com> wrote:
>> On May 29, 2011, at 2:58 PM, Thaddee Tyl wrote:
>>> ... I believe that, given the fact that browsers will implement
>>> ES.next incrementally, we should find a way to allow graceful
>>> fallback, rather than version-driven conditionals.
>> 
>> This is trivial for new global object properties, but such additions in the
>> past, even including JSON, have been breaking changes for some web sites.
> 
> They have coped with that by using polyfills such as:
> 
>  if (!this.JSON) {
>    this.JSON = {};
>    ...
>  }

That's not what I was referring to. The problem was a few years ago some Facebook JS defined a JSON object with Encode and Decode methods (if memory serves), no stringify or parse. It also detected this.JSON but assumed that property value being truthy meant that its own non-ES5 Encode and Decode methods were present.

Polyfills are great but they arise a posteriori. The hard case is when someone in 2006 defined their own JSON, and it did not match what ES5 would standardize years in the future. Same thing that happened with JSON could happen with the new global and Object properties in ES.next.

IIRC the same thing happened with Object.keys, so this is not just about global properties. It's a risk in the pre-module world. With Harmony modules, the requiring code names the module and composes names using lexical scope.


> For most of the soft breakers, people will *definitely* want to check
> for implementation backing.

It's hard to disagree with "people will *definitely*". Some surely will.


> For things like proper tail calls, feature
> detection can mean performance tuning;

This is unlikely to be autoconf-tested. Lack of it means a stack overflow exception, which may take a while. I think this is an extremely unlikely thing for developers to want to foist on users, or get away with if they try.


> for typeof null it means that
> we can make sure that, in all cases, our code won't break.

If you mean typeof code can be written to work in both old and new versions, yes -- we covered that after the January meeting, IIRC.


> For the syntax breakers, however, browsers will, indeed, have to
> implement all those features in one shot. They cannot do it
> incrementally, or else ES.next-only code may very well break.

This is a bit overstated. All open-source browsers implement piecewise in their nightly build channels or repositories. Even IE in its platform previews since 9 and on into 10 has produced some new pieces of whole standards for testing. This is a good thing.

In final releases, we'd like all or nothing, but there's no "cannot" -- if you mean "must not", nothing stops a repeat of IE9, which had ES5 support except for strict mode.


> What do you think? Should we force browser vendors to implement
> soft-breakers in one shot too, even though we could let them do it one
> feature at a time via feature detection?

What makes you think "we" can "force" anyone to do otherwise?

Software doesn't come together in one perfect big-bang integration. Neither do standards. Indeed we need both incremental standards drafting *and* prototype implementation of drafts in order to produce a better standard. ES.next and even strawmen for Harmony editions after it should be prototyped and tested in nightly builds, platform previews, and the like.

The coordination among vendors is a good topic for TC39 when we get further along, but it's really not productive to try to "force" anything yet. And it would be counterproductive to punish vendors that prototype-implement strawmen in order to assess implementability, usability, and other qualities we want in the next edition of the standard.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110530/f132a6e9/attachment.html>


More information about the es-discuss mailing list