On class literals possibly not making it into ECMAScript.next

Brendan Eich brendan at mozilla.com
Sun Nov 6 15:12:39 PST 2011


On Nov 6, 2011, at 3:29 AM, Joe Developer wrote:

> jQuery is a somewhat poor / extreme example - jQuery has taken a monolithic approach to code structuring - while more modern and full featured frameworks tend towards load-on-demand, and hence can offer 'capability-loading'.
> 
> That said, I do think that it is worth keeping in mind that there will continue to be a considerable lag between ES.current and ES.baseline for browser apps - when you guys introduce constructs such as |>

It's <| for now, but may change.


> in lieu of 'jury-riggable' approaches such as commandering Object.extend etc then it means that such code will be subject to de-facto environment lockin and running in 'less capable' environments will require maintaining separate codebases / transpile steps.
> 
> The goal may be to make JS easier - but it is more likely to have the opposite effect, code containing |> will straight up break outside of controlled environments.
> 
> When I see things like |> and .{ I get a bit queasy, but as long as you guys also cater for more backwards compatible constructs I guess we can all get along. 

We do want APIs where possible. Sometimes there's no exact correspondence but something that is more of a companion, which can be used from non-ES6 scripts too. We have agreement to look into exposing built-in modules to unversioned script in a general fashion (e.g., Object.system is the system module loader, so Object.system.load("@name"...) gets you the private name objects built-in module).

/be

> 
> 
> On Sat, Nov 5, 2011 at 7:25 AM, Rick Waldron <waldron.rick at gmail.com> wrote:
> Still the same point, unified API under single namespace, for the same reasons. ES.next will still exist in the same hostile web of today.
> 
> /Rick 
> 
> On Nov 4, 2011, at 8:19 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
> 
>> I think we are arguing different points: All I meant is – how would you structure jQuery in ECMAScript.next (in the future, using the proposed modules)?
>> 
>> On Nov 5, 2011, at 1:14 , Rick Waldron wrote:
>> 
>>> ...But that's not the point. The point is to have a _single_ namespaced, unified API; this helps keep the library small, reduces potential conflict with other libs, makes it easier to learn, easier to extend and easier to maintain. 
>>> 
>>> jQuery deals in reality, not the fantasy world of spec drafts and syntax bikeshedding, and that reality is the web _today_. To be clear, you're aware that jQuery supports a completely compatible API across all browsers that it supports, right? That means that nothing goes into jQuery that cannot be reproduced in... 
>>> 
>>> IE 6, 7, 8 & 9 
>>> Firefox 3.6, 6 & 7
>>> Chrome 14, 15
>>> Safari 5, 5.1
>>> Opera 11.01, 11.5
>>> 
>>> It's not productive to suggest that jQuery has done some kind of "poor man's module" or that it could've done better if it had modules, or that it should, or even might be able to take advantage of some kind of bleeding edge ES.next Module system. jQuery promises that it will not break back compat from one release to the next, and when we do, we _hustle_ to get point release bug fixes out the door. When 24.6 million[1] sites are using a piece of code - because they can trust that it works and that it won't wreak havoc on their site from one version to the next.
>> 
>> -- 
>> Dr. Axel Rauschmayer
>> axel at rauschma.de
>> 
>> home: rauschma.de
>> twitter: twitter.com/rauschma
>> blog: 2ality.com
>> 
>> 
>> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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


More information about the es-discuss mailing list