jQuery named defines

[Guy Bedford]

Hi all,

I've run into a bit of an issue with jQuery named defines. jQuery 2.0.0 and jQuery 1.9.1 could possibly need to run together on a site. Currently, the only way to make this happen is to actually edit the jQuery source and remove the named define when using AMD.

Just checking we are strongly advocating the use of anonymous defines?

The above is worrying me a little at the moment, because if named defines get too widely used, we lose a lot of flexibility with AMD.

Comments welcome,

Guy

[Cristiano Belloni]

+1. From the require.js docs:

You may encounter some define() calls that include a name for the module as the first argument to define():

    //Explicitly defines the "foo/title" module:
    define("foo/title",
        ["my/cart", "my/inventory"],
        function(cart, inventory) {
            //Define foo/title object in here.
       }
    );

These are normally generated by the optimization tool. You can explicitly name modules yourself, but it makes the modules less portable -- if you move the file to another directory you will need to change the name. It is normally best to avoid coding in a name for the module and just let the optimization tool burn in the module names. The optimization tool needs to add the names so that more than one module can be bundled in a file, to allow for faster loading in the browser.

[James Burke]

Yes, anonymous modules should be the norm. jQuery is a bit special,
some details here:
https://github.com/jrburke/requirejs/wiki/Updating-existing-libraries#wiki-anon

James

> --
> You received this message because you are subscribed to the Google Groups
> "amd-implement" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to amd-implemen...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Guy Bedford]

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.

The route I am taking to sort this out, is to provide an "ad-hoc" conversion service on jspm to remove named defines. Forking repos is not an option.

[James Burke]

On Wed, May 1, 2013 at 10:56 AM, Guy Bedford <guybe...@googlemail.com> wrote:
> 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
wild:
https://github.com/jrburke/requirejs/wiki/Updating-existing-libraries#wiki-anon

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.

James

[Guy Bedford]

Yes I understand there are tradeoffs to be made, and I believe that the decision for jQuery to have a named define has been the best one from the various perspectives. It's just that I'm noticing other modules copying this blindly, without reading the documentation, and this is causing the pattern to spread.

So my primary consideration here was how to approach this concern when it comes to package management, and the conclusion I've now made is that package managers will need to provide module conversion for these sorts of situations, which is exactly what I am working on currently.