I agree, however Patch versus Put is the least of Rails' problem when it comes to bloat. Put vs Patch is bikeshedding.
An insistence on handling all things with Ruby is why things get bloated and stop progressing.
Sprockets solves a pain, I admit, but at the cost of adding ruby bloat to all thick client code.
Instead of being able to use javascript libraries with one another natively, everything goes through Ruby.
Anyways, I'll probably get downvoted for this comment by Railers because this is somewhat OT and trollish (I admit), but it's a legitimately complaint about the direction of Rails.
I think Rails has lost sight of what it does really well, server-side logic. Rails, in v4.0, needs to adopt a symbiotic relationship with thick-client javascript instead of trying to consume it and insert ruby in-between all the javascript parts.
For example, right now, the recommended place for a backbone.js app in a rails project is /app/assets/javascripts/. That "folder" is only going to grow as the client-side javascript becomes more important. Keeping the javascript logic "subordinate" to the Ruby elements in a Rails project causes more bloat than anything else. Look at any thick-client Rails project and count the number of gems managing javascript. If there are more than two or three, you've probably got a separation of concerns issue at the language level. That's bloat.
If you want to down vote me, go ahead. I just ask that you have the courtesy to defend your down vote with a comment. If you think I'm wrong tell me why. Maybe, I'm doing something wrong.
"Keeping the javascript logic "subordinate" to the Ruby elements in a Rails project causes more bloat than anything else. "
I have no idea what this means. how is it subordinate? The location on the filesystem?
"Look at any thick-client Rails project and count the number of gems managing javascript"
I've made a few that have no gems managing javascript. They talk to rails via REST. Rails doesn't need to care about them, and they don't need to care about rails.
By subordinate, I mean having your javascript assets managed by sprockets.
If you can tell me how I can get 100% of my javascript assets managed by javascript code and still allow the use of rspec for end to end acceptance testing, I'm all ears. How do you get Rails, at one point of contact, to had off all asset recompilation, concatenation, minification, cache busting through md5 fingerprint hashing, etc. to javascript, I'm all ears.
I wanted to use require.js before. Spent a couple days working it into the project, but couldn't get it to work because of incompatibilities with sprockets. Undid everything. Someone made a require.js rails plugin, and I tried it again. It turned out to be incompatible with how the jasmine gem works and the jasmine gem is organized the way it is because that's how gems are supposed to be organized. Again, after wasting several days trying trying to get everything to work, I tore it all out again.
It's like whoever designed sprockets hasn't even considered the possibility that maybe it should permit javascript to be used freely with javascript within a Rails projects without intermediating. Near as I can tell, all the intermediation is done to be able to such things as maintaining all the files in the same directory organization (app, config, lib, vendor).
I'd split things down into something like this to cleanly separate the concerns of ruby and javascript:
/client/
--/app/
--/config/
--/lib/
--/vendor/
--/spec/
/server/
--/app/
--/config/
--/lib/
--/vendor/
--/spec/
/shared/
--/stylesheets/ (if you render both static and dynamic. otherwise put this in the appropriate directory above)
--/config/
--/spec/acceptance/
How do you keep all your ruby out of your javascript?
It seems to me that your complaint is that Rails isn't written in javascript. If I'm understanding correctly, you want javascript on the backend. That's fine, but it's not really a critique of rails.
p.s. you don't have to use sprockets if it doesn't fit your needs. Your javascript can live outside of your rails app.
Thick javascript clients should probably live in a different project anyway. Create a rails project with the serverside stuff, a rest service layer. And another project containing just the clientside code, no ruby at all.
Then how do you test it if it's in another project? If you want to start stubbing out server logic in client tests and vice versa on the other side that seems very cumbersome and brittle.
An insistence on handling all things with Ruby is why things get bloated and stop progressing.
Sprockets solves a pain, I admit, but at the cost of adding ruby bloat to all thick client code.
Instead of being able to use javascript libraries with one another natively, everything goes through Ruby.
Anyways, I'll probably get downvoted for this comment by Railers because this is somewhat OT and trollish (I admit), but it's a legitimately complaint about the direction of Rails.
I think Rails has lost sight of what it does really well, server-side logic. Rails, in v4.0, needs to adopt a symbiotic relationship with thick-client javascript instead of trying to consume it and insert ruby in-between all the javascript parts.
For example, right now, the recommended place for a backbone.js app in a rails project is /app/assets/javascripts/. That "folder" is only going to grow as the client-side javascript becomes more important. Keeping the javascript logic "subordinate" to the Ruby elements in a Rails project causes more bloat than anything else. Look at any thick-client Rails project and count the number of gems managing javascript. If there are more than two or three, you've probably got a separation of concerns issue at the language level. That's bloat.
If you want to down vote me, go ahead. I just ask that you have the courtesy to defend your down vote with a comment. If you think I'm wrong tell me why. Maybe, I'm doing something wrong.