r.js: Understand requirejs's r.js optimizer

Question

im trying to figure out if its a good idea to use r.js from require.js to generate a build.js file out of my javascript files to only load one file on production. But im wondering if this is a good idea in my case as it seems its simply loading absolutely everything into the DOM using up a lot of memory. Maybe i got it wrong.

Look at one of my backbone based views i implemented using require.js. As i know, r.js will take this file and optimize and put it into the final build.js file with all the others views, models and collections defined the same way.

define(function (require) {
  "use strict";

  var $                   = require('jquery'),
      _                   = require('underscore'),
      Backbone            = require('backbone'),
      tpl                 = require('text!tpl/start.html'),
      Mustache            = require('mustache'),
      template            = Mustache.compile(tpl);

  return Backbone.View.extend({
    initialize: function () {
    },

    render: function () {
      this.$el.html(template());
      return this;
    },

    events: {
      'click #submit': "start"
    },

    start: function (event) {
       // stuff to do ...
    }
  });
});

I guess the final build.js will simply take my code above and concat them into it, right? So this means when i update my index.html loading require.js then my build.js file, it will simply load all the views, models and collections into the DOM. Doesn't take that up too much memory, since i don't need everything to be loaded from the beginning. Does it make sense to call require('path/to/my/view') when its loaded already via the build.js file?

Answer 1

It might indeed not make sense for your application to optimize all modules into one single file. r.js supports this kind of scenario. What you have to do is use the modules option and define as many output files as you need. A generic illustration of this could be:

modules: [
    {
        name: 'main', 
        exclude: [ "viewA", "viewB" ],
    },
    {
        name: 'viewA',
        exclude: ['core']
    },
    {
        name: 'viewB',
        exclude: ['core']
    }
]

The setup above assumes that the source to be optimized has modules named main, viewA and viewB. It would create 3 optimized bundles: a core that contains all core modules that would be loaded in any case, viewA which represents a group of modules to be loaded in circumstances so and so, and viewB which represents a group of modules to be loaded in other circumstances.

How you should setup your modules parameter depends on the specifics of your application.