Interesting post. I've used Laravel for a few years now for work and personal projects, and I've really enjoyed it. I tried to test out Rails to explore other MVC web frameworks, and I just couldn't vibe with it. I think the major areas in which I was incompatible with Rails were:
- Lack of dependency injection/inversion of control. I find it interesting the author lists this as an advantage. With Rails, I was always a little anxious not knowing where things were defined or being implemented.
- Validation happens on models, not requests. With Laravel, I really appreciate being able to validate pretty much any data coming into the application regardless of whether or not it ends up in the database. With Rails, I tried to look for something similar to FormRequest and its validation rules, but I couldn't find many solutions. I think it might just be one of those things that's not the "Rails way".
- Perhaps more of a Ruby issue than a Rails issue, but the dynamism of the language - especially in its type system - was a bit of a drawback for me. I really appreciate PHP 8 and newer versions of Laravel for their support in type hinting and static analysis; being able to mouseover anything and know pretty confidently what I'm working with is a huge boon in my productivity.
I definitely agree with the author on a lot of the Laravel tooling stuff. I've learned to just kind of ignore most of the offerings outside of the core framework. I'm sure it's all great, but there's always a bit of churn in Laravel as the author mentioned so I'd rather save myself the future heartbreak.
aantix
The inherent structure of a Rails app is something that I still love to this day.
I can look at the url of a new or old Rails app and predict consistently what routes, models, controllers and views exist within the app.
Convention over configuration keeps winning.
ch4s3
The author should be careful of what they’re wishing for with respect to ActiveRecord callbacks. They’re sort of what people might call a sharp knife. You can get a lot done quickly but easily end up with something that’s dangerous to operate later.
hokumguru
In regards to the authors complaint about ERB vs Blade I’ve had the same thoughts and have been absolutely delighted by the third party Phlex view system for rails: https://www.phlex.fun/
zerr
I recall an interesting post about switching from Rails back to PHP in 2007
- Lack of dependency injection/inversion of control. I find it interesting the author lists this as an advantage. With Rails, I was always a little anxious not knowing where things were defined or being implemented.
- Validation happens on models, not requests. With Laravel, I really appreciate being able to validate pretty much any data coming into the application regardless of whether or not it ends up in the database. With Rails, I tried to look for something similar to FormRequest and its validation rules, but I couldn't find many solutions. I think it might just be one of those things that's not the "Rails way".
- Perhaps more of a Ruby issue than a Rails issue, but the dynamism of the language - especially in its type system - was a bit of a drawback for me. I really appreciate PHP 8 and newer versions of Laravel for their support in type hinting and static analysis; being able to mouseover anything and know pretty confidently what I'm working with is a huge boon in my productivity.
I definitely agree with the author on a lot of the Laravel tooling stuff. I've learned to just kind of ignore most of the offerings outside of the core framework. I'm sure it's all great, but there's always a bit of churn in Laravel as the author mentioned so I'd rather save myself the future heartbreak.