Yes, because having Rails serving the single page application front-end makes total sense.

The static assets are actually served by nginx. In cases where some page data is dynamically generated by Rails, it's nice to keep both pieces of code together in a mono-repo. That said, when I recently extracted a Backbone app from the Rails codebase (retrofitted Grunt.js), I decided to ditch the public/symlink approach and split the app over 2 subdomains. What I find now is that I like the mono-repo approach, and would be fine with cramming both codebases together, while having granular and global deployment scripts.

I actually do this: I ended up leveraging sprockets to get some environment interpolation (like API locations) and easy preprocessing languages (e.g. coffeescript). Also, by doing this, I don't have to make everything single-page. I can build one off pages if I want to (not that it happens much, but, still). Also I get some nice bits for logging, metric agents integrate easily, etc. I realize I didn't need it, but, there really wasn't a down side to using it, except for that some views ended up a little fragmented when using angular templates in public/ versus actual views... Even then, it was a decent learning experience and I'd probably do it again just for the interpolation and sprockets asset building.

Is isomorphic such a bad idea?