ChatGPT解决这个技术问题 Extra ChatGPT

Why did Underscore.js remove support for AMD?

1.3.0 — Jan. 11, 2012 Removed AMD (RequireJS) support from Underscore. If you'd like to use Underscore with RequireJS, you can load it as a normal script, wrap or patch your copy, or download a forked version.

Why have they done it? Does anyone know? Because they added it only few month ago (in October), and AMD (Asynchronous Module Definition) is said to be far superior to CommonJS modules.

Update: As of December 2013, this has been supported again.

I hope you can link to a post, mail discussion, or twitter comment with motivation for this act or clarification from developers.
Asynchronous Module Definition not Advanced module loader, see github.com/amdjs/amdjs-api/wiki/AMD
so far, the most prominent voice of AMD being said to be far superior to commonjs/etc is the creator of require.js himself. i'm less inclined to take blindly the opinions of the creator of a particular method than i am to listen to a community of people, and thus far, the jury's still out.

C
Community

Jeremy gave his reasoning in the comments of the commit:

Yep. Not supporting a particular script loader will definitely make it easier for all of them to work properly. I apologize for merging the support in the first place.

He also tweeted a bit more on the change (link from a later comment):

… because AMD support is breaking regular Underscore embeds on pages that also happen to use Require.js …


@SalmanPK This change just means that underscore is loader-agnostic now. So, you're free to set it up for any loader you need. How is that a bad thing?
Because now we can't use it with any AMD compatible loader (RequireJS, Almond.js, curl.js, lsjs, bdLoad, Yabble etc) without extra configuration or manual editing.
@SalmanPK Use a fork that's dedicated to Underscore for AMD, then: github.com/amdjs/underscore.
Note: As now mentioned in the question, Underscore is AMD compliant again, as of December 2013.
@BradParks Thanks for the clarification.
A
Andrew Marshall

The developers of Underscore thought that having AMD support would break support on non-AMD enabled scripts. This is actually not the case, as you can have a script that is both AMD-enabled but also works as-is on a non-AMD deployment.

There is now a drop-in replacement for Underscore: Lo-Dash. Which, along with other features not in Underscore, includes AMD/non-AMD duality.


I think this answer is underrated. However, I feel the tone of this answer (intentional or not) is condescending towards the underscore developers, which I do not think is appropriate.
lodash sounds cool, but I don't see how this answers the question
I agree with both of you - it doesn't really answer on the 'why'. Instead it quickly gives a drop-in alternative. So I am editing the answer a little bit
Z
ZenMaster

I felt the need to add to this fairly old question.

Both Backbone and Underscore now support AMD:

Underscore commit Backbone Commit

Discussions (albeit Backbone's one is a bit puzzling as there is a clear discrepancy between the tone of the discussion and the actual outcome):

Underscore Issue Backbone Issue


m
mikemaccana

ES5-shim provides many of the same features as underscore and lodash (array.forEach(), array.map() etc).

ES5-shim natively supports AMD, unlike underscore and lodash, doesn't add extra copies of things your browser probably already provides. Rather it adds native ES5 features to older browsers.

When IE8 and other older browsers die out, you can simply remove the ES5-shim dependency without having to port code like you would with lodash or underscore.


the question was not about features of underscore library, but rather about reasons for such (controversial / opaque) architectural choice.
@c69 Understood, but the lodash answer also doesn't cover the reasons for removing AMD from underscore. Since that answer is highly moderated, I thought pointing out that using ES5 itself / ES5 shim for older browsers presents a more future-safe alternative.