jQuery AMD example, regarding: https://tech.bellycard.com/blog/the-future-of-jquery/

jquery_amd.js

define([

  // jquery core is always required
  'jquery/core',

  // jquery utilities
  'jquery/ajax',
  'jquery/data'

], function(jq, ajax, data) {

  // Using the core module, create a jQuery instance
  // with the required extensions
  var $ = jq.require(ajax, data);
  
  // The local instance of $ contains the necessary jQuery
  // extensions, but once this module is done executing,
  // "$" no longer exists to other modules.

});

If jQuery's source is broken into modules that return the definition for that utility, and the core module contains a build or require method that extends the core api with the extended api definitions (ajax, data, etc), that build/require method would clone the jQuery namespace with the required extension definitions (ajax/data). Which would allow $('element').data('name') in the scope of the current module only.

I imagine internal dependencies would remain as they are now, the difference would be what the modules would return, and how the jq.build method would handle them.

Can you expand upon what you mean by building as a static file?

Today, there is a single global object and a single prototype for that object that contains the union of all methods that may be called on that method. Here you are essentially creating several disjoint jQuery instances, similar to where a user loads jQuery multiple times with jQuery.noConflict(). Even if you avoid actually loading multiple copies of the JavaScript source, you'll still have different instances. That is a problem when it comes to things like $("#element").data("mydata") because each instance will keep its data storage segregated and that is probably not what you want. Also it will run any initial module initialization, including time-consuming feature detects, once for each unique instance. And then you have to decide how to use this scheme with a third-party plugin where the dependencies are not described or exposed.

I just don't see why people are so obsessed with breaking jQuery up into tiny little parts when it buys so little.

Yes, I'm sure this isn't as easy as it appears. I completely understand that. Some of the core internal concepts may have to change. There wouldn't be an initial feature detect for every new instance, this should only happen once.

The point is not that the instances are completely segregated (data stores, etc, may be accessible from all instances), the idea is that the API is only accessible if required, and in the end only gets included in the production source if necessary.

There would be no conflicts, because there would be no global object.

@tbranyen's take: https://gist.github.com/tbranyen/9255362

I'd break them apart and leave them apart personally, things like requests have no place in jquery proper IMO

@dmethvin, I think @davearel has a point. There is nothing stopping us from still having shared state amongst instances which all have different external Apis based on need.

I agree with @visionmedia's point, but I don't see that happening.

Conversation has migrated to: https://gist.github.com/tbranyen/9255362