amd.md

AMD Pros

• No build step
• CORS loading of modules
• etc...

No build step.

Genuine use case. I appreciate that.

However in some / most cases having an optimizing build step is worth while, in those cases you have a build step anyway so the advantage is lost.

CORS loading of modules

Unless your loading say https://amdjs.org/jquery/2.1.3 loading arbitrary scripts at arbitrary versions is very dangerous. Having hard experience with dependending on semver ranges in node & browserify, patch version changes break back compat some times which lead to production bugs at arbitrary times.

Hence fixing versions is worthwhile.

If your going to load jQuery@2.1.3 remotely over CORS then you could also have loaded it locally because it exists and you can download and bundle it.

One valid use case to do this is a shared CDN to take advantage of CORS caching shared among many users. This again is only valid for modules that are popular and is an exception to the norm.

Few months ago I'd have said better debugging experience in AMD. But since source maps this is not valid for modern browsers. Debugging has been always hard in old browsers.

Having used requirejs for long time it's been always hard to setup, urls, no optimized vs , shims, libraries that support and not, libraries with anonymous define and named defined. More than once you have to dig in the library to see if it has AMD support or not, and if it does support how.

"CORS loading of modules" is a bit misstated. The only use-case AMD solves in this regard:

• Loading of modules from other domains
• Which don't have CORS enable for those resources
• And have been prepackaged as AMD format

Any CDN should probably be enabling CORS for resources it wants people to be able to load from other domains.