AMD modulization support

[Taybin Rutkin]

AMD modules are an increasingly popular way to prevent namespace pollution. It would be great if Strophe could be packaged with support for this.

The code for this can be as simple as:

var args = arguments;
if ( typeof define === 'function' && define.amd ) {
    // register with AMD as a module
    define( function () {
        var Strophe = args[0];
        Strophe.$build = args[1];
        Strophe.$msg = args[2];
        Strophe.$iq = args[3];
        Strophe.$pres = args[4];

        return Strophe;
    });
} else {
    window.Strophe = arguments[0];
    window.$build = arguments[1];
    window.$msg = arguments[2];
    window.$iq = arguments[3];
    window.$pres = arguments[4];
}

The only remaining problem is how to package MD5 and Base64? They can either be wrapped into their own modules, in which case they need to be distributed in their own files, or they can be compiled together using r.js.

That seems like a big change to the build system though, so I'm a little stuck on what would be appropriate here.

[Jack Moffitt]

Is there any tangible benefit to this? Strophe already is well namespaced (modulo Function.prototype.bind, which I plan to remove).

It also has no issue with being loaded asynchronously that I am aware of.

[Taybin Rutkin]

Well the issue as I see it is Base64, MD5, Strophe, and the $foo helpers going into the global namespace. I would like to avoid possible conflicts with other libraries. This might not be likely with Strophe and the $foo helpers, but it seems very possible for Base64 and MD5.

This also helps with minification. Since Strophe will become a local variable, it will optimize Strophe.getNodeFromJide() down to (likely) a.getNodeFromJid(), a small improvement.

That said, it's true that Strophe's lack of dependencies makes a major benefit of AMD irrelevant.

[Taybin Rutkin]

I'm happy to provide the pull request. I'd just like to discuss it first. Allowing the continued use of Strophe without requiring AMD is also a requirement, clearly.

[Taybin Rutkin]

Thinking about this a little more, it seems to me that the main issue is Base64 and MD5 being exported as globals. If they were somehow in the Strophe namespace be default, they could continue to be exported to the global namespace (preserving backwards compatibility for anyone using them) and could remain wrapped if and AMD environment is detected, leaving us with just the simple patch above.

The only issue I see is that I'm not sure how that could be done with your current build system where Base64 and MD5 are in their own files.

[Lee Boynton]

I guess the main benefit of having AMD support is that module loaders like require.js can be used with strophe.

What's the problem with having the MD5, base64 and (recently added) sha1 as separate modules?

[Aria Stewart]

I'm interested in this as well -- I want to build an app into a single file, and already use require.js to do the rest. It'd be nice to have it all in one place.

[Lee Boynton]

For an example of a tangible benefit: Currently I have an issue with some users where the Base64 global variable seems to have been overwritten, and no longer has a 'decode' method. This means these users can't authenticate.

Using AMD and thereby no longer polluting the global namespace would mean there would be no conflicting global variables. This means that Strophe can play nicer with other JS libraries.

[isfarax]

I started out with Strophe.js back in 2010 and I have found my self needing to use for AMD simply because.

Strophe.js AMD? It is efficient, modular and I presume cool - so why not I say???