6 ms·

If PATCH even has a remote chance of breaking 0.01% of sites, then WHY do it? PUT works fine. I don't care. Well, this "if it even remotely breaks 0.01%" and "

by batista 15y ago

If PATCH even has a remote chance of breaking 0.01% of sites, then WHY do it? PUT works fine. I don't care. Well, this "if it even remotely breaks 0.01%" and "I don't care" attitude is the main reason things get bloated and stop progressing.

moe 15y ago
We seem to have different ideas of progress. To my eye Rails is picking up bloat like there's no tomorrow and happily adopting questionable decisions like the above. Meanwhile fundamental issues remain largely unaddressed. There's still serious performance regressions. The asset pipeline is still sort of a trainwreck. There's still no automation for schema migrations (perhaps hobo fields will finally bring some relief for those who adopt it). They still don't seem to have realized that code generators are a no-go. I see zero efforts towards modernizing the bloated routing and MVC cruft to accomodate modern fat-clients (and imho the "resources"-magic was a terrible idea from the start even for regular apps). The whole thing is still riddled with ungodly amounts of magic that likes to break in unpredictable ways (my pet bug: the monkey-patch to really suppress browser stack-traces in production changes about every 3 months and it's worrying such a bug was deliberately created in first place). I could go on for a while... </rant>
- fxn 15y ago
  Patches welcome!
  - malandrew 15y ago
    I think the problem is beyond being solvable by patches, but an issue of philosophical introspection of where Rails wants to be in a few years. To be able to change the direction of Rails on this issue and the other issues the poster above raised, I'd have to spend a significant amount of time submitting patches and get to the point where I am a major committer to have the opportunity to chime in and have a significant impact on the direction Rails is going. Even if I or someone else with the same concerns were committed to making that effort, by the time I or they get to the point where we can have an impact, it will be too late. I'd rather commit to a node or an npm package than rails because any package I commit to will hopefully be replaced by something better once it's outlived its usefulness. My favorite part about node is that it isn't opinionated. It leaves the opinion to the community modules. Hopefully most community modules with maintain just the right amount of opinion about their domain and know when to concede matters of opinion to other modules that node better. It's nice when separation of concerns is a cultural value. This isn't a node/rails debate. It's a values debate. I think opinion was the right value for the right time several years ago. We're going through a time of change where opinion is a liability not an asset.
    - homosaur 15y ago
      Does this mean it's time to fork?
      - virmundi 15y ago
        This is a horrible issue with modern development. Basically we are getting into sectarianism. Don't like a doctrine of the Brethren Church? Fork and become the Grace Brethren. Don't like a small doctrine of the Grace Brethren? Fork and make the Conservative Grace Brethren. I know that GIT and the like have made it really easy to fork and run, but does this fundamentally help? Does having X versions of some framework really make sense? Why not go a different route and just give up the one side and make another? Rather than forking, make something new.
        homosaur 15y ago
        Yeah, I actually think that's the way to go if you don't like Rails, I was kind of joking. I am curious to see if there's enough passion for Rails itself that people would say, "no I want RAILS, even if it means making it something else" rather than just accepting a change in philosophy or moving to something else. Personally, I think there's not. I think people either are sticking to Rails or they are not. I think even if you don't like the new Rails, it did help the development community at large. Before Rails, I don't know many web folks who were talking about TDD and MVC and real, honest, programming stuff.
        dlitz 15y ago
        > I know that GIT and the like have made it really easy to fork and run, but does this fundamentally help? Yes, it does. What ends up happening in practice is that forks are almost always short-lived. They either get merged with the mainline, they become the new mainline, or they die out. Occasionally, there are two self-sustaining projects that diverge from the same point of origin, but it's rare.
      - malandrew 15y ago
        Naw, if you work with Ruby, I'd just work on creating an ecosystem of interchangeable parts around Sinatra.
  - rohitarondekar 15y ago
    It's unfortunate that this being down voted. Because he means it sincerely.
  - eta_carinae 15y ago
    The "If you're not happy submit a patch or shut up" is exactly the arrogant and absurd attitude that kills open source projects.
    - cheald 15y ago
      No, "I'm not happy and it's your job to fix it" is exactly the arrogant and absurd attitude that kills open source projects.
      - Confusion 15y ago
        Downvoted you both. Both attitudes are neither arrogant nor absurd. They just stem from different expectations and beliefs. These kind of statements aren't going to convince anyone. Explain why they are wrong. 'Being arrogant' is not an explanation: it's an accusation, that'll immediately get the other on the defensive.
        nknight 15y ago
        If you really need an explanation for why slavery is wrong, I think you're beyond reasoning with.
        Confusion 15y ago
        I don't understand your comment. Are you suggesting one side of the above argument implicitly condones slavery? Or do you feel that my argument is invalid, because it could equally apply to a discussion about slavery in which people resort to name calling?
        nknight 15y ago
        Now you're just being deliberately obtuse. Nobody needs to be told that demanding unpaid labor of open-source contributors is condoning slavery, and nobody is owed an explanation of why unless they're a small child or mentally handicapped.
  - eta_carinae 15y ago
    The "If you're not happy submit a patch or shut up" response is exactly the arrogant and absurd attitude that kills open source projects.
  - Confusion 15y ago
    The question is whether the patches would be accepted. There are still people in charge. When they make a choice to go route A and you say: I have a great patch to make route B work, they are not going to take it. Secondly, if you disagree with an architectural decision, you can't be expected to make the chosen architecture work. Especially not if your patch may be rejected anyway. The number of patches that get rejected is staggering. Practice shows that 'patches welcome' is just not true.
- apsurd 15y ago
  re: asset pipeline It's beyond me why rails thinks it should dictate how to write/manage/package javascript. As a newbie-ish javascript developer I am continually learning from great projects like requirejs, enderjs, nodejs, commonjs (AMD in general), backbonejs, etc. How arrogant do rails programmers have to be to dip their hand into javascript best practices? Honest question, because the better I get at programming the more I feel like rails is less necessary.
  - Fluxx 15y ago
    They're not dictating how you use JS, best practices, or anything like that, it's simply a pipeline for compressing and delivering assets. You also don't have to use it if you don't want to. There is a "config.assets.enabled" option in application.rb that you can set to "false" to turn it off. Bottom line is Rails is, and always has been, and opinionated framework, which you choose to buy in to. And even in recent years they've been better about letting you opt out of certain parts of it.
    - rohitarondekar 15y ago
      Why is this being down voted? It's true.
  - grabastic 15y ago
    How do you minify and concatenate your files in your projects? Part of a deploy/build script? Commit hooks? Manually? Do you do it at all? What about compiling Sass and CoffeeScript? The asset pipeline is not arrogance it's convenience. If you have a better system for those tasks then you shouldn't use the pipeline, but for a lot of people the asset pipeline saves time and results in a faster, better experience for their end users.
    - zachrose 15y ago
      +1. I've watched people reinvent the asset pipeline on top of the asset pipeline.
    - malandrew 15y ago
malandrew 15y ago
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.
- jshen 15y ago
  "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.
  - malandrew 15y ago
    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?

by batista 15y ago

moe 15y ago

We seem to have different ideas of progress. To my eye Rails is picking up bloat like there's no tomorrow and happily adopting questionable decisions like the above. Meanwhile fundamental issues remain largely unaddressed. There's still serious performance regressions. The asset pipeline is still sort of a trainwreck. There's still no automation for schema migrations (perhaps hobo fields will finally bring some relief for those who adopt it). They still don't seem to have realized that code generators are a no-go. I see zero efforts towards modernizing the bloated routing and MVC cruft to accomodate modern fat-clients (and imho the "resources"-magic was a terrible idea from the start even for regular apps). The whole thing is still riddled with ungodly amounts of magic that likes to break in unpredictable ways (my pet bug: the monkey-patch to really suppress browser stack-traces in production changes about every 3 months and it's worrying such a bug was deliberately created in first place). I could go on for a while... </rant>

fxn 15y ago
Patches welcome!
- malandrew 15y ago
  I think the problem is beyond being solvable by patches, but an issue of philosophical introspection of where Rails wants to be in a few years. To be able to change the direction of Rails on this issue and the other issues the poster above raised, I'd have to spend a significant amount of time submitting patches and get to the point where I am a major committer to have the opportunity to chime in and have a significant impact on the direction Rails is going. Even if I or someone else with the same concerns were committed to making that effort, by the time I or they get to the point where we can have an impact, it will be too late. I'd rather commit to a node or an npm package than rails because any package I commit to will hopefully be replaced by something better once it's outlived its usefulness. My favorite part about node is that it isn't opinionated. It leaves the opinion to the community modules. Hopefully most community modules with maintain just the right amount of opinion about their domain and know when to concede matters of opinion to other modules that node better. It's nice when separation of concerns is a cultural value. This isn't a node/rails debate. It's a values debate. I think opinion was the right value for the right time several years ago. We're going through a time of change where opinion is a liability not an asset.
  - homosaur 15y ago
    Does this mean it's time to fork?
    - virmundi 15y ago
      This is a horrible issue with modern development. Basically we are getting into sectarianism. Don't like a doctrine of the Brethren Church? Fork and become the Grace Brethren. Don't like a small doctrine of the Grace Brethren? Fork and make the Conservative Grace Brethren. I know that GIT and the like have made it really easy to fork and run, but does this fundamentally help? Does having X versions of some framework really make sense? Why not go a different route and just give up the one side and make another? Rather than forking, make something new.
      - homosaur 15y ago
        Yeah, I actually think that's the way to go if you don't like Rails, I was kind of joking. I am curious to see if there's enough passion for Rails itself that people would say, "no I want RAILS, even if it means making it something else" rather than just accepting a change in philosophy or moving to something else. Personally, I think there's not. I think people either are sticking to Rails or they are not. I think even if you don't like the new Rails, it did help the development community at large. Before Rails, I don't know many web folks who were talking about TDD and MVC and real, honest, programming stuff.
      - dlitz 15y ago
        > I know that GIT and the like have made it really easy to fork and run, but does this fundamentally help? Yes, it does. What ends up happening in practice is that forks are almost always short-lived. They either get merged with the mainline, they become the new mainline, or they die out. Occasionally, there are two self-sustaining projects that diverge from the same point of origin, but it's rare.
    - malandrew 15y ago
      Naw, if you work with Ruby, I'd just work on creating an ecosystem of interchangeable parts around Sinatra.
- rohitarondekar 15y ago
  It's unfortunate that this being down voted. Because he means it sincerely.
- eta_carinae 15y ago
  The "If you're not happy submit a patch or shut up" is exactly the arrogant and absurd attitude that kills open source projects.
  - cheald 15y ago
    No, "I'm not happy and it's your job to fix it" is exactly the arrogant and absurd attitude that kills open source projects.
    - Confusion 15y ago
      Downvoted you both. Both attitudes are neither arrogant nor absurd. They just stem from different expectations and beliefs. These kind of statements aren't going to convince anyone. Explain why they are wrong. 'Being arrogant' is not an explanation: it's an accusation, that'll immediately get the other on the defensive.
      - nknight 15y ago
        If you really need an explanation for why slavery is wrong, I think you're beyond reasoning with.
        Confusion 15y ago
        I don't understand your comment. Are you suggesting one side of the above argument implicitly condones slavery? Or do you feel that my argument is invalid, because it could equally apply to a discussion about slavery in which people resort to name calling?
        nknight 15y ago
        Now you're just being deliberately obtuse. Nobody needs to be told that demanding unpaid labor of open-source contributors is condoning slavery, and nobody is owed an explanation of why unless they're a small child or mentally handicapped.
- eta_carinae 15y ago
  The "If you're not happy submit a patch or shut up" response is exactly the arrogant and absurd attitude that kills open source projects.
- Confusion 15y ago
  The question is whether the patches would be accepted. There are still people in charge. When they make a choice to go route A and you say: I have a great patch to make route B work, they are not going to take it. Secondly, if you disagree with an architectural decision, you can't be expected to make the chosen architecture work. Especially not if your patch may be rejected anyway. The number of patches that get rejected is staggering. Practice shows that 'patches welcome' is just not true.
apsurd 15y ago
re: asset pipeline It's beyond me why rails thinks it should dictate how to write/manage/package javascript. As a newbie-ish javascript developer I am continually learning from great projects like requirejs, enderjs, nodejs, commonjs (AMD in general), backbonejs, etc. How arrogant do rails programmers have to be to dip their hand into javascript best practices? Honest question, because the better I get at programming the more I feel like rails is less necessary.
- Fluxx 15y ago
  They're not dictating how you use JS, best practices, or anything like that, it's simply a pipeline for compressing and delivering assets. You also don't have to use it if you don't want to. There is a "config.assets.enabled" option in application.rb that you can set to "false" to turn it off. Bottom line is Rails is, and always has been, and opinionated framework, which you choose to buy in to. And even in recent years they've been better about letting you opt out of certain parts of it.
  - rohitarondekar 15y ago
    Why is this being down voted? It's true.
- grabastic 15y ago
  How do you minify and concatenate your files in your projects? Part of a deploy/build script? Commit hooks? Manually? Do you do it at all? What about compiling Sass and CoffeeScript? The asset pipeline is not arrogance it's convenience. If you have a better system for those tasks then you shouldn't use the pipeline, but for a lot of people the asset pipeline saves time and results in a faster, better experience for their end users.
  - zachrose 15y ago
    +1. I've watched people reinvent the asset pipeline on top of the asset pipeline.
  - malandrew 15y ago

malandrew 15y ago

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.

jshen 15y ago
"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.
- malandrew 15y ago
  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?