|
|
|
|
|
|
by afuchs
561 days ago
|
|
|
> Could you give some examples of what the use cases are where Rails makes it hard to stray from the beaten path? Rails is amazing for greenfield projects. It will automatically do things for you which will greatly reduce the amount of boilerplate you need to write as long as you follow the framework's conventions. However, Rails has a less than stellar reputation from those who have maintained long lived projects which use it. Rails' conventions encourage the use of fat models where business logic is implemented in the models themselves.
With the default scaffolding Rails provides, every single model and all of this business logic ends up in the project's app/models/ directory without any separation between different features. Because the default doesn't cleanly separate business logic with well defined boundaries this means that Rails apps tend to evolve in a way where everything starts to become tightly coupled with everything else. When the business requirements for the application inevitably change this tendency towards tight coupling between models makes it difficult to make major changes to existing code. I've also seen hacky workarounds used in Rails based apps which exist to make complex business logic work (e.g., saving one model doesn't implicitly trigger hooks for business logic on other related models). These hacky workarounds usually break the conventions Rails uses and ends up requiring extra boilerplate to be added elsewhere in the application. Some developers try to avoid this by hand rolling more architectural layers (e.g., "Java/Go/Node.js/OOP like") on top of Rails to try prevent this, to varying degrees of success. Other frameworks (e.g., Django) try to encourage developers to separate different features into distinct modules to try and prevent them from being tightly coupled with each other. |
|
|