On class literals possibly not making it into ECMAScript.next

Joe Developer joe.d.developer at gmail.com
Sun Nov 6 03:29:02 PST 2011

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

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 |> 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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111106/8fafe656/attachment-0001.html>

More information about the es-discuss mailing list