7 ms·

> but whatever the volume individually, collectively it adds up to a lot of negativity Nope. Plenty more people love rails and contribute improvements to it th

> but whatever the volume individually, collectively it adds up to a lot of negativity Nope. Plenty more people love rails and contribute improvements to it than loath it and bash it. > the building blocks of a Rails application scale really, really badly as a codebase grows uh - i slide a slider in heroku. Others add machines behind a load balancer. Shopify does 18000/reqs/sec on rails. The "rails doesn't scale" argument died years ago. > You find yourself longing for POROs, hating the complexities of ActiveRecord callbacks when dealing with subclasses of models, cursing the way instance variables you set on a base controller somewhere end up being referenced inside view templates No, I don't. these are all things I like about rails. > the bitter taste in the mouth that prolonged Rails exposure leads to. can definitely sense the bitterness... > Whereas for Rails, the all-consuming vision of what the framework should be requires them to put in, amongst all the goodness, the bad stuff that causes people so much grief in the end. No idea what this "bad stuff" is. The author isn't a rails developer, and that's fine. But that doesn't mean rails is broken, or wrong, or bad; despite contrary portrayals. It just mean Rails isn't for them. They make it sound like it's some monster to work with and grow - it's the exact opposite. It's streamlined to be easy to grow and work on; which makes working on it enjoyable. Nothing in ruby will unseat rails for web frameworks; short of rails stopping development. And personally, I am yet to see a more effective and enjoyable framework; nothing really comes close with the speed and power rails provides; where one developer can deliver their product to all platforms, reusing much of the same views and controllers, delivering changes instantly; it still amazes me.

boffinism 9y ago
To be fair, the point about "the building blocks of a Rails application scale really, really badly as a codebase grows" is not about performance, it's about code manageability. Also, just because more people love Rails than loathe it in no way negates the point that there is a lot of negativity. The two are orthogonal.
- meesterdude 9y ago
  > it's about code manageability. I've worked on plenty of large rails codebases, and many times I can just dive right in and start contributing. Any codebase can grow to be unwieldy, but once you understand rails and other code organization techniques in ruby it's not an issue if you take the time to groom things. Code manageability in rails is a highlight. > the point that there is a lot of negativity But there isn't a lot. there are a few people who dislike it, and often their points are just because they prefer something different. It's well tested, performant, and has a large community - and been around for over 10 years.
Rafert 9y ago
It's not 18k req/s, but 80k: https://youtu.be/N8NWDHgWA28 https://youtu.be/N8NWDHgWA28
- meesterdude 9y ago
  whaaaaaat? wow. i was totally off.
vertex-four 9y ago
I've been watching my partner try and build a web app "the Rails way" for the past couple of weeks. The result has been huge amounts of pain any time slightly not-off-the-shelf functionality is desired, especially when Devise or email is involved. It's supposedly great, otoh, if you're working on a CRUD app with minimal requirements, you're not that big into TDD, or if all the complex stuff in your app actually lives on another service that you can talk to over e.g. RabbitMQ that isn't tied down by Rails.
- dchuk 9y ago
  Can you give real examples? I've always heard this complaint about Rails but have also built a few large apps in it and never felt these problems myself.
  - nimblegorilla 9y ago
    I think a lot of the problem comes from Rails ease of setup. You can get Devise working in about 10-20 minutes. Then you want to customize something and it takes an afternoon to figure out. With any other framework that's par for the course. Yet somehow developers expect rails to spoon-feed them the entire way.
  - vertex-four 9y ago
    A couple of specific issues include that email to multiple users is difficult to get right - googling for it results in a number of weird hacks, with Rails providing nothing itself, and the most obvious mechanism involving a lot of logic in your controllers - and Devise's invitations stuff is very inflexible, making a number of assumptions about what data should be stored (invitation timestamps being the major one). Given that a goal of this specific app is to store as little data as possible, that's unacceptable, and resulted in a fair bit of monkeypatching. And that seems to be the core of it - monkeypatching things or depending on implementation details seems to be the norm when trying to get Rails and its supporting ecosystem to do something other than what it does by default, and that's difficult to maintain over the long term. And if you can't depend on Rails and co being flexible enough to do what you want, you might as well build on a less-opinionated framework from the start and skip the step of trying to bend Rails into shape.

boffinism 9y ago

To be fair, the point about "the building blocks of a Rails application scale really, really badly as a codebase grows" is not about performance, it's about code manageability. Also, just because more people love Rails than loathe it in no way negates the point that there is a lot of negativity. The two are orthogonal.

meesterdude 9y ago
> it's about code manageability. I've worked on plenty of large rails codebases, and many times I can just dive right in and start contributing. Any codebase can grow to be unwieldy, but once you understand rails and other code organization techniques in ruby it's not an issue if you take the time to groom things. Code manageability in rails is a highlight. > the point that there is a lot of negativity But there isn't a lot. there are a few people who dislike it, and often their points are just because they prefer something different. It's well tested, performant, and has a large community - and been around for over 10 years.

Rafert 9y ago

It's not 18k req/s, but 80k: https://youtu.be/N8NWDHgWA28 https://youtu.be/N8NWDHgWA28

meesterdude 9y ago
whaaaaaat? wow. i was totally off.

vertex-four 9y ago

I've been watching my partner try and build a web app "the Rails way" for the past couple of weeks. The result has been huge amounts of pain any time slightly not-off-the-shelf functionality is desired, especially when Devise or email is involved. It's supposedly great, otoh, if you're working on a CRUD app with minimal requirements, you're not that big into TDD, or if all the complex stuff in your app actually lives on another service that you can talk to over e.g. RabbitMQ that isn't tied down by Rails.

dchuk 9y ago
Can you give real examples? I've always heard this complaint about Rails but have also built a few large apps in it and never felt these problems myself.
- nimblegorilla 9y ago
  I think a lot of the problem comes from Rails ease of setup. You can get Devise working in about 10-20 minutes. Then you want to customize something and it takes an afternoon to figure out. With any other framework that's par for the course. Yet somehow developers expect rails to spoon-feed them the entire way.
- vertex-four 9y ago
  A couple of specific issues include that email to multiple users is difficult to get right - googling for it results in a number of weird hacks, with Rails providing nothing itself, and the most obvious mechanism involving a lot of logic in your controllers - and Devise's invitations stuff is very inflexible, making a number of assumptions about what data should be stored (invitation timestamps being the major one). Given that a goal of this specific app is to store as little data as possible, that's unacceptable, and resulted in a fair bit of monkeypatching. And that seems to be the core of it - monkeypatching things or depending on implementation details seems to be the norm when trying to get Rails and its supporting ecosystem to do something other than what it does by default, and that's difficult to maintain over the long term. And if you can't depend on Rails and co being flexible enough to do what you want, you might as well build on a less-opinionated framework from the start and skip the step of trying to bend Rails into shape.