Running SPDY locally helps a lot. Even with all those files I hit DOMReady at about 2.7s with no concatenation.
Every time I've encountered requirejs in an application this has been representative of my experience with the tool and the pain of having to wait that long every time I reload a page simply doesn't seem worth it to me. There's also somewhat of a mismatch between async loading assets in development and sync loading them in production which I've seen responsible for bugs that show up in one environment but not the other, and/or vice versa.
A couple of questions for you: do you think the r.js optimizer taking 2.5s to compile is related to the complexity of the dependency tree in your application or just the number of files being loaded? Also, considering the previously mentioned mismatch between dev/prod and async loading, do you think it is appropriate to use something like SPDY to obviate the pain of a lengthy DOMReady event in development?
[1] - http://searls.testdouble.com/posts/2013-06-16-unrequired-lov...
Using r.js in development isn't the worst idea. It's worth seeing how long it takes in order to make that decision. Compiling tpls is much faster (grunt-contrib-jst) and adding that to your grunt watch & including it directly is a good way to save time. I think it takes a long time on my end due to the complexity of the dependencies. I only include exactly what each module needs so some dependencies may be as many as 6 levels deep, or more (haven't really checked).
SPDY makes a big difference for me (big enough to ignore the problem for now) and I don't mind using a self-signed cert in dev.
EDIT: I hadn't been compiling tpls using JST in dev until I wrote this post - a great side effect is, it actually shows me now where the errors in my tpls are! Previously any tpl's stack terminated at the code that ajaxed in the tpl. This is far better for debugging and brought my DOMReady time down to about 1.75s.
Instead of having >200 files that need to be compiled with r.js every time, what about compiling them to intermediary builds? Abstract your code in to some bigger modules and wrap them up in a little bow with a nice interface, and basically consider that part of the code "solved" and focus only on what is currently changing or being built. Your build process should reflect this!
I've been doing this on larger projects with RequireJS and r.js and my build times are very short... it just builds from maybe 15-20 files, where a few of those files are the result of some other r.js build.
Now, should r.js possibly do things to better manage this sort of approach? You bet! There are many mature build environments that have a similar approach. Maybe r.js needs some sort of concept of "linking"?
Personally, I don't mind having to manage intermediary builds, because... that intermediary build is making something that I can use in OTHER projects... I haven't really come across a situation where pure business logic is dominating an application. Almost everything that a program does can be abstracted out and reused! I'm sure people out there can provide plenty of examples to the contrary, and I'd love to hear those!