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
