6 ms·

I'm Switching from Laravel to Rails

54 points by ksec 2y ago

hokumguru 2y ago
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/ https://www.phlex.fun/
aantix 2y ago
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.
- rawfan 2y ago
  Same as Laravel, IMHO.
- npteljes 2y ago
  >Convention over configuration keeps winning. That is 100% true. Convention is an agreement we already had. It's much less effort, and more manageable to learn that, with the potential downsides as well, compared to figuring out the particulars of a custom configuration.
ch4s3 2y ago
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.
- seattle_spring 2y ago
  > You can get a lot done quickly but easily end up with something that’s dangerous to operate later. That's my experience with all of Rails.
  - nullserver 2y ago
    Flipside, you can get a lot done with rails very quickly, so your odds of success are much higher.
  - ch4s3 2y ago
    I think Rails is great if you don't go wild with things like callbacks, 10s of levels of partial nesting, and mystery behavior included in controllers. If you keep your gem use sane too, you'll be fine.
  - qudat 2y ago
    Agreed. The fundamental design flaw with Rails: https://bower.sh/on-autoloading https://bower.sh/on-autoloading
    - ch4s3 2y ago
      Autoloading is fine as long as you don't go nuts with gems or write classes that will stomp on other implementations of a namespace if autoloaded. The UX as the article concedes is great most of the time. The problem usually arises when someone pulls in a gem that does a ton of class opening and can poison the rest of the application with unexpected behavior. Yes, making you vulnerable to this is a downside of autoloading, but its within your control when adding new code.
      - qudat 2y ago
        Knowing where things are defined is table stakes. A language that supports making it nearly impossible to find a function definition is objectively bad.
        ch4s3 2y ago
        My point is that it’s only hard to know that if you create that problem yourself in rails, with some exceptions in ActiveSupport. The system just allows you to make that mistake, but experienced practitioners generally will not do that.
sirolimus 2y ago
this Planning on going full-in on rails soon
- aantix 2y ago
  The new Turbo 8 morphing is incredibly productive for building dynamic sites. Start with that pattern from the beginning.
  - sirolimus 2y ago
    Thanks, will check that out. I’m completely unfamiliar with the ruby ecosystem coming from the npm world
_peeley 2y ago
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.
- johnny22 2y ago
  > 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. This is why i switched from rails to symfony even though I hadn't had experience with those kinds of systems before. I took to it rather well
- tmm84 2y ago
  Pretty much my experience as a frontend guy that had to fill in for a team reduction and had to start working on the Rails side of things. I always felt like I was just having to "know" what was going to happen. Unit tests, mocks, etc. were all coming back "ok" but there was always something in production that would act up. I had never this happen with the Java and PHP backends that I always had to touch up when there wasn't much talent available. Before I was let go from the Rails client I suggested that they invest in property based testing for all code as it was quite clear there were cases that weren't being thought of that existed in the application somewhere (undocumented, manually added, etc.).
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
zerr 2y ago
I recall an interesting post about switching from Rails back to PHP in 2007 https://sive.rs/rails2php https://sive.rs/rails2php

54 points by ksec 2y ago

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/ https://www.phlex.fun/

aantix 2y ago

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.

rawfan 2y ago
Same as Laravel, IMHO.
npteljes 2y ago
>Convention over configuration keeps winning. That is 100% true. Convention is an agreement we already had. It's much less effort, and more manageable to learn that, with the potential downsides as well, compared to figuring out the particulars of a custom configuration.

ch4s3 2y ago

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.

seattle_spring 2y ago
> You can get a lot done quickly but easily end up with something that’s dangerous to operate later. That's my experience with all of Rails.
- nullserver 2y ago
  Flipside, you can get a lot done with rails very quickly, so your odds of success are much higher.
- ch4s3 2y ago
  I think Rails is great if you don't go wild with things like callbacks, 10s of levels of partial nesting, and mystery behavior included in controllers. If you keep your gem use sane too, you'll be fine.
- qudat 2y ago
  Agreed. The fundamental design flaw with Rails: https://bower.sh/on-autoloading https://bower.sh/on-autoloading
  - ch4s3 2y ago
    Autoloading is fine as long as you don't go nuts with gems or write classes that will stomp on other implementations of a namespace if autoloaded. The UX as the article concedes is great most of the time. The problem usually arises when someone pulls in a gem that does a ton of class opening and can poison the rest of the application with unexpected behavior. Yes, making you vulnerable to this is a downside of autoloading, but its within your control when adding new code.
    - qudat 2y ago
      Knowing where things are defined is table stakes. A language that supports making it nearly impossible to find a function definition is objectively bad.
      - ch4s3 2y ago
        My point is that it’s only hard to know that if you create that problem yourself in rails, with some exceptions in ActiveSupport. The system just allows you to make that mistake, but experienced practitioners generally will not do that.

sirolimus 2y ago

this Planning on going full-in on rails soon

aantix 2y ago
The new Turbo 8 morphing is incredibly productive for building dynamic sites. Start with that pattern from the beginning.
- sirolimus 2y ago
  Thanks, will check that out. I’m completely unfamiliar with the ruby ecosystem coming from the npm world

_peeley 2y ago

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.

johnny22 2y ago
> 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. This is why i switched from rails to symfony even though I hadn't had experience with those kinds of systems before. I took to it rather well
tmm84 2y ago
Pretty much my experience as a frontend guy that had to fill in for a team reduction and had to start working on the Rails side of things. I always felt like I was just having to "know" what was going to happen. Unit tests, mocks, etc. were all coming back "ok" but there was always something in production that would act up. I had never this happen with the Java and PHP backends that I always had to touch up when there wasn't much talent available. Before I was let go from the Rails client I suggested that they invest in property based testing for all code as it was quite clear there were cases that weren't being thought of that existed in the application somewhere (undocumented, manually added, etc.).

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

zerr 2y ago

I recall an interesting post about switching from Rails back to PHP in 2007 https://sive.rs/rails2php https://sive.rs/rails2php