Cappuccino's @import does this really well: it is both asynchronous and blocking. In other words, having three @imports one after the other will all load in parallel (without having to explicitly request it, even if they are separated by other lines of code), but the code itself will not execute until the imports are done:

    @import "one.js" // loaded in parallel to the other two
    @import "two.js" // loaded in parallel to the other two

    code code code // this is run only after one.js and two.js (but not three.js) have been loaded and run

    @import "three.js" // loaded in parallel to the other two

Very nice! Just a note: that seems to break some things that Ruby developers take for granted, like importing stuff conditionally, or importing a bunch of files in a loop. Or is there some other way to do that?

There are JavaScript APIs in the loader you can call directly, but they will be asynchronously loaded and executed (so you'll need to pass in a callback)

Basically the only way to get this asynchronously loading / synchronously executing behavior is to statically analyze your "root" module for dependencies and load them (and their dependencies, etc). Once they're all loaded you can begin execution and synchronously execute every module as they're imported.

FYI CommonJS (not AMD) loaders for the browser do the same thing to avoid synchronous XHRs that will cause the UI to hang.

You can still import things conditionally (its treated as a statement), the only real restriction is that the filename is expected to be a static string, so the for loop thing wouldn't work. However, the "guts" of the import statement are also provided to you as a function that you can just call with anything, so you could still have for (;blah;) objj_import(filenames[i], callback) for these kinds of cases.

Spine uses HEM which allows you to develop your apps using separate files (in JS or CS), it basically uses the CommonJS spec AFAIK.

Then when you want to move from development to production it concatenates and minifies all the files for improved network performance.

Actually I'd rather not see the JS framework itself trying to solve this problem. The Rails asset pipeline (based on Sprockets) is an example of a good solution to this problem that is completely agnostic to your JS framework.

I'm serving a substantial Amber app this way and it works great. I'm taking it a step further by writing most of my code in Coffeescript, and I keep all my Handlebars templates in separate files as well. Sprockets just magically combines it all.

You could also look at YUI. YUI3 is built from the bottom up with that mentality: keep a file for each class, merge them in the build stage into one module file and serve all modules combined automatically.

Take a look at MooTools. It's built around a module/class based philosophy that makes it easy to not only configure the framework itself into what you need (the framework is built around several dozen small files), but to do the same thing to your code as well.

bpm (http://www.getbpm.org/) works with Amber and compiles multiple Javascript, SCSS and Coffeescript into a single JS and CSS file. It also has a mode where it does it in realtime for development use.

Browserify lets you require stuff if you're used to node paradigms.

https://github.com/substack/node-browserify

Amber's object model is very powerful. It has mixins and easy-to-use inheritance. You can reopen classes too.

We're definitely aware of this issue and are working on some solutions that should be relatively painless.

brunch (http://brunch.io) provides this for backbone.js / eco / stylus - it merges multiple source files into a single deployable js (and css) file. Or you could use spine, which has this out of the box.

SproutCore has supported this since 2007.