3 ms·

Your comment comes across as narrow-minded and frankly, a bit arrogant. It is just so dismissive. Rails's original popularity came from developers fleeing the e

Your comment comes across as narrow-minded and frankly, a bit arrogant. It is just so dismissive. Rails's original popularity came from developers fleeing the excessive ceremony and boilerplate code of enterprise Java – and .NET to some extent. Sure, there are some inexperienced (or simply bad) developers in the Rails community, just as there are in every community. But most of the Rails developers I've met also have experience in at least one other major web stack. They're not chasing "shiny magic features". They're chasing productivity. For me personally, Rails offers greater productivity than any other web framework I've used. The truth is Ruby has little to do with that, as much as I happen to like the language. I could go on for quite a while about why I feel Rails offers the best productivity, but it boils down to two main points: the entire Rails community is focused on building web applications, and the Rails core team is mostly comprised of people actually building web applications. Features get added because they're needed. Common frictions get ironed out. Rails isn't about "magic". Rails is about getting shit done, quickly and mostly-cleanly.

askyourmother 10y ago
Uhhm, it certainly is about magic, it's creator goes on about that quite a bit. So the happy meal developers don't really have to know how to code. Just install these gems, copy these incantations from the pragprog book, you too can have your site in five minutes. You don't need to understand the shiny magic, I mean, it detracts from being saying "I'm a Rails developer", but maybe it would help if they did.
- Tenhundfeld 10y ago
  I'm curious to see examples of the shiny magic you're talking about. Honestly. I can think of some conventions that seemed a little magical at first but make more sense once you understand what's really happening under the hood. Have you worked much in Rails? I'm asking, because it sounds like your exposure is mostly from demos and blog posts, which are obviously going to use the five-minute, "happy meal" examples. A complex, real-world application is very different from a presentation where somebody whips together a blog engine in 15 minutes. For example, I can't remember the last time I saw somebody use the scaffold generator for production functionality, other than maybe for temporarily mocking up some functionality for stakeholder feedback. I'm wondering if some of our difference in opinion is just based on Rails appearing easy to use. Take ActiveRecord for example. Sure, you don't need to understand SQL and database engines to get started using it, but if you're going to build anything serious, you better understand how to drop down to raw SQL when necessary, how indexing works in a RDBMS, etc. I personally think ActiveRecord, while a bit bloated, is a great mix of making the simple stuff extremely easy and getting out of my way when I need to do something more sophisticated. And I think that applies to Rails overall. It makes the simple, routine stuff very easy, and it lets me do more sophisticated things with minimum complexity overhead. All of that said, my opinion is based on my experiences. It sounds like you've seen/had other experiences with Rails, maybe systems built by less mature developers. I've inherited some bad Rails systems, but I've inherited just-as-bad systems built in Java, .NET, PHP, Javascript, etc.

askyourmother 10y ago

Uhhm, it certainly is about magic, it's creator goes on about that quite a bit. So the happy meal developers don't really have to know how to code. Just install these gems, copy these incantations from the pragprog book, you too can have your site in five minutes. You don't need to understand the shiny magic, I mean, it detracts from being saying "I'm a Rails developer", but maybe it would help if they did.

Tenhundfeld 10y ago
I'm curious to see examples of the shiny magic you're talking about. Honestly. I can think of some conventions that seemed a little magical at first but make more sense once you understand what's really happening under the hood. Have you worked much in Rails? I'm asking, because it sounds like your exposure is mostly from demos and blog posts, which are obviously going to use the five-minute, "happy meal" examples. A complex, real-world application is very different from a presentation where somebody whips together a blog engine in 15 minutes. For example, I can't remember the last time I saw somebody use the scaffold generator for production functionality, other than maybe for temporarily mocking up some functionality for stakeholder feedback. I'm wondering if some of our difference in opinion is just based on Rails appearing easy to use. Take ActiveRecord for example. Sure, you don't need to understand SQL and database engines to get started using it, but if you're going to build anything serious, you better understand how to drop down to raw SQL when necessary, how indexing works in a RDBMS, etc. I personally think ActiveRecord, while a bit bloated, is a great mix of making the simple stuff extremely easy and getting out of my way when I need to do something more sophisticated. And I think that applies to Rails overall. It makes the simple, routine stuff very easy, and it lets me do more sophisticated things with minimum complexity overhead. All of that said, my opinion is based on my experiences. It sounds like you've seen/had other experiences with Rails, maybe systems built by less mature developers. I've inherited some bad Rails systems, but I've inherited just-as-bad systems built in Java, .NET, PHP, Javascript, etc.