On Wed, May 1, 2013 at 10:56 AM, Guy Bedford <guybe...@googlemail.com
> The thing is, all other libraries will copy jQuery when it comes to
> implementing AMD!
> So we are setting a standard that will now be copied, and is being copied,
> when it shouldn't be.
I was hoping that we can point library authors to docs like the
following if they needed guidance, or if we come across it in the
The other solution was to not have jQuery participate as a define()'d
module, and given that it is big anti-pattern to need two jQuerys in a
page, it seemed like a reasonable tradeoff to have the named define.
Multiple jQuerys do happen though, although they are more likely mixed
case ones: jQuery loaded on the page, but not part of an AMD load, and
one where it is used for AMD modules. So to avoid errors in that case,
the named define was used.
I'm open to figuring out how to avoid the errors, but I have taken
about three shots at it over the years, and could not make it work, at
least with script-src-based loaders. The story may actually get better
over time, but as long as IE9 and below are to be supported, it is
difficult to work around.
The tricky thing is that if jQuery goes with an anonymous define,
given its legacy use in non-AMD cases, it can generate errors that
could be reported to the jQuery team. I prefer to not place that
burden on them.
Getting modules on the web is difficult. There are tradeoffs until it
gets into the language/browser natively. The other more general use
cases outweighed the cost for the "multiple jQuerys in an AMD system"
use case. At least in my mind.