I think there are 2 things at play that prevent a rails-like monolithic framework for js at the moment:
1) Front-end applications tend to have wider variation in functionality requirements from the start (real-time, graphs, animations, forms, modals, pushstate). There isn't a "standard CRUD app" that people are building with front-end js, often js is just being used for a single effect or widget.
2) Performance tradeoffs are very tangible to end-users. For instance, in most cases, straight HTML is still lighter and snappier than an AngularJS app (until you click on something, then that's another tradeoff) but an app served by 2 rails servers will usually be indiscernible from one served by 1 sinatra server.
With rails, you can say that the performance penalties are worth productivity gains because those penalties are really only going to effect deployment costs, not the UX. With JS, every extra bit you add to your framework is going to effect UX.
For me, the biggest pain is still dependency management. Bower is great for pulling stuff in but then I have to blend it with requirejs or an AMD loader or hand-wire it into my html. Likewise, when I want to remove something I have to touch a bunch of files. I'd love to just be able to "bower install backbone" and get back to writing code but building such a feature would require bower to be able to understand my project's structure.
Your last sentence is specially interesting. Being able to do a "bower install backbone" and going back to work is actually the purpose of a package manager. If it doesn't understand your project structure and is not able to wire the downloaded libraries into your project, whats the point of using it? Then bower is as good as npm or any other tool to download libraries. Right?
What bower manages is downloading dependencies at a specific version and putting them in a folder. It does not wire/unwire them into my index.html. At this point I have to do that by hand. There are a lot of ways my project could be laid out. I might only want d3.js on my dashboard page, I might have a layout template where all of my html imports reside. I might want the files all concatenated together and downloaded in the browser as a single main.js. In it's current incarnation it's still a package manager... it makes packages available at a path. It's just not as useful as it could be if it were a bit more specific about project structure.
1) Front-end applications tend to have wider variation in functionality requirements from the start (real-time, graphs, animations, forms, modals, pushstate). There isn't a "standard CRUD app" that people are building with front-end js, often js is just being used for a single effect or widget.
2) Performance tradeoffs are very tangible to end-users. For instance, in most cases, straight HTML is still lighter and snappier than an AngularJS app (until you click on something, then that's another tradeoff) but an app served by 2 rails servers will usually be indiscernible from one served by 1 sinatra server.
With rails, you can say that the performance penalties are worth productivity gains because those penalties are really only going to effect deployment costs, not the UX. With JS, every extra bit you add to your framework is going to effect UX.
For me, the biggest pain is still dependency management. Bower is great for pulling stuff in but then I have to blend it with requirejs or an AMD loader or hand-wire it into my html. Likewise, when I want to remove something I have to touch a bunch of files. I'd love to just be able to "bower install backbone" and get back to writing code but building such a feature would require bower to be able to understand my project's structure.