You should rather ask what the difference to almond is (which is also from jburke and useful for bundled loading - I think this is more similiar to define.js).
almond: 275 LOC
As to a reason why someone would write his own AMD loader:
I once wrote one, because I want'ed to be able to pass objects as array elements to the require parameter, to forward them to the callback function. Something similiar to this:
Thus I got something similiar to Function.bind() for free.
Also I could implement a global requirement list. A synchronous script in the head could add entries to this list and thus prevent the execution of any asynchronous script, which was not in the list. Thus those in the list could be loaded asynchronously. After all of them where resolved, all the others could be loaded.
I guess I could open source it, if I feel like it. :D
Edit: Fixed LOC numbers. I also just checked my implementation: Only 168 LOC, while nearly implementing AMD (without relativ paths!), tuned for Closure/uglify.js/etc. and compatible to IE6, but with those 2 features above. I guess that's pretty good too…
@prayerslayer: nothing wrong with require.js, the main goal is to create a more portable alternative and more importantly to add couple of new and nonstandard ways of modular coding as a proposal for the JavaScript community.
I'd rather see technical details too plus maybe a comparison between require.js/almond and define.js. Currently it's not clear what are the advantages of define.js.
Examples would be nice. I'm not especially a require fanboy, I use almost exclusively ES6 modules nowadays, but i'm not sure to understand what your library brings.
I'm having trouble understanding why I would use this over ES6 modules, or even RequireJS/Almond? The README comes across as more of a blog post than technical documentation.
I'm all in for more choices in AMD implementations, but why doesn't this expose the standard `require` and `define` methods? I do get that I'm supposed to map them myself, but then again I have no clue what advantage I get from this?
Actually in the current version to expose them to the global scope, you should add the global attribute to your script tag and pass the window as it's value, like global="window".
One of the main goals here is to provide developers the ability of exposing it to different globals with different behaviors and configuration, which is not possible yet in this version, but it will be there in the next couple of hours.
If it's just a snippet, and require.js made up 20% of the filesize, then why not just have a single file, or assume a single closure and concatenate a few files together? You'll gain even better filesize from minifying inside a single closure. The formalised step up from this is SMASH, which is how d3 is built: https://github.com/mbostock/smash
IMO, a big upside of using a define / require pattern, even when the final library is fully concatenated, is that you have a clear picture of all of variables that are available in a particular module.
It's a little ambiguous when using something like Smash, since you're not actually importing a module onto a variable.
As someone unfamiliar with the codebase, it's unclear to me where many of the variables are coming from (d3_interpolate, d3_rgb_names, d3_interpolateRgb, etc).
It'd imagine it makes managing dependencies a bit trickier.
Well yes, it's not ideal for all development, but you professed a need for smaller filesize, which it's ideal for. Naming conventions can alleviate most of the variable issues, it's just another way to solve the problem that has some advantages and disadvantages.
(I don't use it myself, due to the current project being too large, so I use require.js in conjunction with amdclean which removes a lot of the module loader overheads.)
26 comments
[ 3.8 ms ] story [ 51.8 ms ] threaddefine.js: 259 LOC
You should rather ask what the difference to almond is (which is also from jburke and useful for bundled loading - I think this is more similiar to define.js).
almond: 275 LOC
As to a reason why someone would write his own AMD loader: I once wrote one, because I want'ed to be able to pass objects as array elements to the require parameter, to forward them to the callback function. Something similiar to this:
Thus I got something similiar to Function.bind() for free.Also I could implement a global requirement list. A synchronous script in the head could add entries to this list and thus prevent the execution of any asynchronous script, which was not in the list. Thus those in the list could be loaded asynchronously. After all of them where resolved, all the others could be loaded.
For instance this is incredibly useful, if you wan't to load IE shims, for things like this: https://developer.mozilla.org/en-US/docs/Web/API/Element.cla... etc.
I guess I could open source it, if I feel like it. :D
Edit: Fixed LOC numbers. I also just checked my implementation: Only 168 LOC, while nearly implementing AMD (without relativ paths!), tuned for Closure/uglify.js/etc. and compatible to IE6, but with those 2 features above. I guess that's pretty good too…
N.b. another AMD loader (30 lines of JS): https://curiosity-driven.org/amd-loader-with-promises
https://gist.github.com/paton/ab27a1be7e843d220ee3
Less than a tweet long when minified :)
If file size is extremely important to your project, I highly recommend using something like this instead of almond.js or require.js.
I run a service that requires our customers to install our Javascript snippet on their page.
Migrating away from require.js reduced file size by ~20%.
It's a little ambiguous when using something like Smash, since you're not actually importing a module onto a variable.
For example, check out this random file from D3 source: https://github.com/mbostock/d3/blob/master/src/interpolate/i...
As someone unfamiliar with the codebase, it's unclear to me where many of the variables are coming from (d3_interpolate, d3_rgb_names, d3_interpolateRgb, etc).
It'd imagine it makes managing dependencies a bit trickier.
(I don't use it myself, due to the current project being too large, so I use require.js in conjunction with amdclean which removes a lot of the module loader overheads.)
use(['dependency'])
.then(function(dependency){
})
.then()
.cache();
Imagine a control flow in the module definition, or having different private scopes when defining a new module.