We ran into the issue with partial loading as well. The solution was not deploying twice but telling the `.(js|coffee).erb` file with the asset_url links which

We ran into the issue with partial loading as well. The solution was not deploying twice but telling the `.(js|coffee).erb` file with the asset_url links which partials it depended on (this seems like it should be unnecessary and handled automatically simply by using asset_url but it isn't). The `//= depends_on` directive handles this for you. You can read the issue I filed here for more information: https://github.com/rails/sprockets-rails/issues/95 https://github.com/rails/sprockets-rails/issues/95. From the issue it looks like they are working on improving this too. We also started out with the more granular module design recommended here but actually found it cumbersome. I recalled over-modularity also being problematic when I used to do .NET. I've found (as have many others I talk to) that most projects should just have a "core" (for services, shared directives and controllers) and "UI" (mostly controllers and application specific directives). In our project we have a "core" which is mostly services and directives and then we break up the rest of the application into separate "app" or "UI" modules which depend on that, these are mostly just controllers. We'll only create other modules if there is an obvious reason to break them out. The easy test is would you package the module up and let it live in it's own repository (maybe as a bower package) in the future. If in doubt, it goes in core. Another thing that helped a lot was switching to using http://rails-assets.org http://rails-assets.org. This made bower integration of 3rd party dependencies far, far, easier. I have not had speed problems with Sprockets yet though I've run into them in the past. We are even passing our bower assets through Sprockets so I'm surprised it's running well. I suppose this could be a version thing (we're using Rails 4). Finally we use Teaspoon to run our tests and I don't bother with AngularJS style integration tests, we test our services mostly and avoid browser automation based testing right now. It is generally cumbersome, slow and unreliable. We try to keep as much logic in the services anyways. All-in-all, I second the sentiment that using AngularJS with Rails has been great and I actually really like Sprockets/Asset Pipeline for working with it.