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 <[email protected]> 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 <[email protected]> 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
>> [email protected]
>>
>> home: rauschma.de
>> twitter: twitter.com/rauschma
>> blog: 2ality.com
>>
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
