3 ms·

But, what's the point of this? How's this an alternative of require.js?

• cj 12y ago
  File size. 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%.
  • vmind 12y ago
    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 https://github.com/mbostock/smash
    • cj 12y ago
      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. For example, check out this random file from D3 source: https://github.com/mbostock/d3/blob/master/src/interpolate/interpolate.js 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.
      • vmind 12y ago
        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.)