4 ms·

I'm not going to be able to comment on everything on this article and it is indeed a wonderfully put together resource, but I must say that I tend to disagree w

I'm not going to be able to comment on everything on this article and it is indeed a wonderfully put together resource, but I must say that I tend to disagree with the over-all premise. Yes, if you are a first time or beginner developer Rails can be overwhelming and you will learn a lot more by using a smaller framework such as Sinatra. On the other-hand if you are undertaking a medium to large scale project (and not a micro-service), you probably want Rails. With Rails you have the benefit of a complete package of libraries that work out of the box and are quite extensively tested. I can almost guarantee everything else will cause you more pains, subjectively, if you really dislike the Rails style, it may be worth it. I also have a minor quibble with the suggestion that multi-level delegation is a good coding pattern - it is a terrible pattern! Have you ever tried to find the function you need through 3-4-levels of delegation when everything extends 5-10 different concerns? I'd much rather read - `self.parent_objects.children.function_name` in my code than `function_name` and then spend time searching where the later came from.

ajmurmann 10y ago
If you have "self.parent_objects.children.function_nam" in your code base is a demeter violation (which I like to see as yet another code smell rather than a law or rule) that is telling you that you are probably missing a domain model. Mixins don't solve that either but hide the smell from you.
- pg_is_a_butt 10y ago
  his whole point was that without the smell, there isn't even a hint where the source is.
- gleenn 10y ago
  GP is not saying mixins solve that problem, they are saying that it further obfuscates where the method is being delegated to. You have to search all the mixins to see who defines the method you are looking for.
angersock 10y ago
Counterargument: nearly every medium-large scale project I've seen in Rails ends up full of mismatched idioms and confused usage of Rails core utilities and just general jankery. Also, Rails 5 is not Rails 4 is sure as hell not Rails 2--as the framework has matured, it's gotten less and less accessible to beginning devs, and has developed a jargon and mindset that sheds very little light on how the Web works under the covers and magic. Starting with Sinatra or similar and building out and up is a much better way to end up with a real understanding of what's going on.
- jeremymcanally 10y ago
  > Counterargument: nearly every medium-large scale project I've seen in Rails ends up full of mismatched idioms and confused usage of Rails core utilities and just general jankery. I think you could remove the word "Rails" and say the same about any medium-large scale software project with several developers working on it. Say what you will about Rails, but after working with it for about a decade, it's actually prevented more confusion and stupidity from creeping into the projects I've worked on rather than enabling it.
  - fbonetti 10y ago
    Totally anecdotal, but the past two startups I worked at used Rails on greenfield projects. The first one decided to go "off the rails" and made up their own architecture based on Uncle Bob's SOLID design principles or whatever. We weren't allowed to use ActiveRecord, which is a huge part of how you handle domain logic, validations, relationships, cascading deletes, and data consistency in Rails. Instead of ActiveRecord Models, we had `repository` classes which basically had a bunch of raw SQL queries, we had `interactor` classes to handle all of our domain logic, and our controllers were just called `interactor` methods and returned the result. The general architectural ideas came from a good place, but going that hard against the "Rails way" made basics tasks extremely difficult. We couldn't use any external Rails gems because our architecture violated the basic assumptions that gem authors made. We had to hand roll all of our validation logic because we couldn't use ActiveRecord. Our DB raised non-NULL exceptions all over the place because people would forget to validate certain fields, or didn't know that certain fields were required because there was no model class to clearly articulate the schema. After just 6 months the code was already a mess. The other company I worked for embraced the "Rails way" completely. The code base accumulated a ton of technical debt and general jankiness along the way, mostly due to constantly changing business logic and integration with 3rd party services like Salesforce, but the code base was surprisingly easy to work with. The company shuffled people to different teams a lot and it wasn't that hard to onboard new devs into a given project. What I'm trying to say in a very long-form way is that Rails, when used as it was intended, works pretty well for medium to medium-large projects. You just have to do what the framework wants you to do. It might seem restrictive, magical, or maybe even stupid, but it will prevent a lot of confusion and pain. If you really dislike the Rails ideology, it's better to just avoid the framework entirely.
smegel 10y ago
Sounds like advice I would give a Python programmer who is considering a micro/mini-framework instead of Django.
- collyw 10y ago
  I never really understood the micro-framework hype. Django is heavyweight, but you don't need to use every feature. And when you do need the feature it will work nicely with the other components.
  - pluma 10y ago
    The argument boils down to "more code, more bugs" so large frameworks are less trustworthy than small libraries. Of course on the other end these popular large frameworks often have a lot more maintainers (sometimes even more maintainers per line of code) than the smaller libraries frequently only maintained by one or two people. And there are of course synergies (yes I'm using that word unironically) when all the code lives in a single ecosystem rather than being based on a unique combination of purpose-built libraries. Having used both Django and Flask, and various front-end frameworks and libraries, I can see the appeal of both sides of the argument. In the end I haven't found either argument to be bullet-proof though. Everything is always a trade-off.
  - bennylope 10y ago
    This is largely true for someone who already knows the framework(s), probably less so when you're learning. There's less to do to make "a thing" that works in Flask than in Django. That said, many of the times I've reached for Flask I've realized, eh, it's going to be just as quick and "light" to do this in Django. At the working, production level, I wholly agree with you.

ajmurmann 10y ago

If you have "self.parent_objects.children.function_nam" in your code base is a demeter violation (which I like to see as yet another code smell rather than a law or rule) that is telling you that you are probably missing a domain model. Mixins don't solve that either but hide the smell from you.

pg_is_a_butt 10y ago
his whole point was that without the smell, there isn't even a hint where the source is.
gleenn 10y ago
GP is not saying mixins solve that problem, they are saying that it further obfuscates where the method is being delegated to. You have to search all the mixins to see who defines the method you are looking for.

angersock 10y ago

Counterargument: nearly every medium-large scale project I've seen in Rails ends up full of mismatched idioms and confused usage of Rails core utilities and just general jankery. Also, Rails 5 is not Rails 4 is sure as hell not Rails 2--as the framework has matured, it's gotten less and less accessible to beginning devs, and has developed a jargon and mindset that sheds very little light on how the Web works under the covers and magic. Starting with Sinatra or similar and building out and up is a much better way to end up with a real understanding of what's going on.

jeremymcanally 10y ago
> Counterargument: nearly every medium-large scale project I've seen in Rails ends up full of mismatched idioms and confused usage of Rails core utilities and just general jankery. I think you could remove the word "Rails" and say the same about any medium-large scale software project with several developers working on it. Say what you will about Rails, but after working with it for about a decade, it's actually prevented more confusion and stupidity from creeping into the projects I've worked on rather than enabling it.
- fbonetti 10y ago
  Totally anecdotal, but the past two startups I worked at used Rails on greenfield projects. The first one decided to go "off the rails" and made up their own architecture based on Uncle Bob's SOLID design principles or whatever. We weren't allowed to use ActiveRecord, which is a huge part of how you handle domain logic, validations, relationships, cascading deletes, and data consistency in Rails. Instead of ActiveRecord Models, we had `repository` classes which basically had a bunch of raw SQL queries, we had `interactor` classes to handle all of our domain logic, and our controllers were just called `interactor` methods and returned the result. The general architectural ideas came from a good place, but going that hard against the "Rails way" made basics tasks extremely difficult. We couldn't use any external Rails gems because our architecture violated the basic assumptions that gem authors made. We had to hand roll all of our validation logic because we couldn't use ActiveRecord. Our DB raised non-NULL exceptions all over the place because people would forget to validate certain fields, or didn't know that certain fields were required because there was no model class to clearly articulate the schema. After just 6 months the code was already a mess. The other company I worked for embraced the "Rails way" completely. The code base accumulated a ton of technical debt and general jankiness along the way, mostly due to constantly changing business logic and integration with 3rd party services like Salesforce, but the code base was surprisingly easy to work with. The company shuffled people to different teams a lot and it wasn't that hard to onboard new devs into a given project. What I'm trying to say in a very long-form way is that Rails, when used as it was intended, works pretty well for medium to medium-large projects. You just have to do what the framework wants you to do. It might seem restrictive, magical, or maybe even stupid, but it will prevent a lot of confusion and pain. If you really dislike the Rails ideology, it's better to just avoid the framework entirely.

smegel 10y ago

Sounds like advice I would give a Python programmer who is considering a micro/mini-framework instead of Django.

collyw 10y ago
I never really understood the micro-framework hype. Django is heavyweight, but you don't need to use every feature. And when you do need the feature it will work nicely with the other components.
- pluma 10y ago
  The argument boils down to "more code, more bugs" so large frameworks are less trustworthy than small libraries. Of course on the other end these popular large frameworks often have a lot more maintainers (sometimes even more maintainers per line of code) than the smaller libraries frequently only maintained by one or two people. And there are of course synergies (yes I'm using that word unironically) when all the code lives in a single ecosystem rather than being based on a unique combination of purpose-built libraries. Having used both Django and Flask, and various front-end frameworks and libraries, I can see the appeal of both sides of the argument. In the end I haven't found either argument to be bullet-proof though. Everything is always a trade-off.
- bennylope 10y ago
  This is largely true for someone who already knows the framework(s), probably less so when you're learning. There's less to do to make "a thing" that works in Flask than in Django. That said, many of the times I've reached for Flask I've realized, eh, it's going to be just as quick and "light" to do this in Django. At the working, production level, I wholly agree with you.