On class literals possibly not making it into ECMAScript.next

Axel Rauschmayer axel at rauschma.de
Fri Nov 4 17:19:10 PDT 2011

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111105/7c1227c7/attachment-0001.html>

More information about the es-discuss mailing list