Sorry it's taken me a bit to get back to this.

When this code runs will depend on the ``require`` configuration, but there's no reason to assume it will generally run later than the non-AMD setup we have now. In the non-AMD version, it runs only after skrollr has been downloaded and executed (since it must be included before skrollr-menu), and then only after skrollr-menu's been downloaded. In the AMD version, the code will run after the AMD loader's been downloaded and executed, and then after the skrollr-menu module's been downloaded. But it won't have to wait for the skrollr module to donwload (AMD loaders download the resources in parallel) or for the skrollr-menu module to start executing (since this code is defined outside the module body). 

Perhaps the bigger issue, though, is that the AMD loader won't block the page's rendering. So even if the browser runs the code at about the same time in either case, it may have already shown the rendered page to the user under the AMD version, causing a visible jump as the code scrolls back to the top. The only way to prevent this, I think, would be to put this code in the HTML directly (making sure it's blocking but not taking an extra request) rather than use AMD. A bit annoying, but probably the best solution.

Re the module's name: it actually [doesn't need](http://requirejs.org/docs/api.html#modulename) one, and not naming it arguably makes it a bit more flexible. Only the ``skrollr`` module needs a hardcoded name, so that the plugins can dependably ``require`` it. With the setup in this commit, someone would require skrollr-menu like this:
``
require.config({
  //many config options go here
  //...
  paths: {
    "myNameForSkrollrMenu": "path/to/skrollr/menu"
  }
});
define(["myNameForSkrollrMenu"], function(skrollrMenu) {
   //my module that depends on skrollr-menu
}
```

Still, we can give it a name if you want.