4 ms·

I got burnt out on Rails after the third app in a row that I was responsible for upgrading. I appreciate Rails' contribution to web development. It took about a

I got burnt out on Rails after the third app in a row that I was responsible for upgrading. I appreciate Rails' contribution to web development. It took about a decade for the front end framework-library ecosystem to figure out that MPAs are more effective than SPAs for most apps. Fortunately, Astrojs is part of the ecosystem. It's sortof like the fullstack JS version of Rails/Sinatra...without the ORM which IMO adds incidental complexity. If you have a thriving business already using Rails, it's difficult to justify moving off of Rails...now that painful upgrades seem to be mostly in the past. However, I do find isomorphic JS components & state management to be a pleasure to develop & maintain compared developing an app in two languages.

throwaway2990 3y ago
I had to upgrade a project from rails 4.2 to 5.0 and it took like 3 weeks because things just broke randomly. Upgraded a .NET 4.7 project to .NET 6 in 3 days and haven’t touched it since. And the .NET project was larger. I haven’t done rails since that upgrade and I hope i never have to touch it again.
- cjblomqvist 3y ago
  Just to highlight; That's 6 major versions of .NET (so at least 7+ years in between). Including the Core era.
cultofmetatron 3y ago
come checkout phoenix. you get a lot of the same batterries included benefits of ror but the architecture is more moduler. runtime performance is closer to go-lang and there's a really fantastic websocket and reactive frontend system built in. Erlang OTP takes it a whole other level beyond that too if you're trying to scale up.
- fredrikholm 3y ago
  > runtime performance is closer to go-lang If you squint, yes. Erlang has had NIFs and ports since forever precisely because it isn't great at CPU intensive tasks. In most cases however, you're still looking at an order of magnitude less servers than the equivalent Rails/Django application.
pelasaco 3y ago
If you plan the updates since the beginning, and are up-to-date with what's coming next, you are good. Having the app dualboot, running it in your CI to catch upcoming changes is a easy way to avoid such headaches
- stevebmark 3y ago
  This is an ironic comment on a Shopify story, they have wasted a lot of time upgrading Rails https://shopify.engineering/upgrading-shopify-to-rails-5-0 https://shopify.engineering/upgrading-shopify-to-rails-5-0
  - pelasaco 3y ago
    yeah people learned with time. Github had the same problem too.https://github.blog/2018-09-28-upgrading-github-from-rails-3-2-to-5-2/ https://github.blog/2018-09-28-upgrading-github-from-rails-3..... in 2023 it is so well documented, and so easy to automate, that shouldn't happen anymore.
    - stevebmark 3y ago
      It's not easy to automate. As you know Github now works directly off the Rails main branch. They have both core Ruby and core Rails maintainers on staff. They have to find, fix, approve, and merge, introduced bugs every day, as well as deal with Rails bugs themselves in the main branch that emerge. This is a huge overhead cost for keeping software up to date, and does not (and should not) apply to any other company.
      - pelasaco 3y ago
        guess what? 99% of the apps are not github, neither shopify. You add to your pipeline some automation with https://github.com/fastruby/next_rails https://github.com/fastruby/next_rails and you are done. I'm maintaing a rails app from 2006, with more than 1000 LC (excluding the 2k specs and views) and we are running on rails 7.1. We had one critical moment around rails 5.2 , but after that we managed to keep our stack always up to date.

throwaway2990 3y ago

I had to upgrade a project from rails 4.2 to 5.0 and it took like 3 weeks because things just broke randomly. Upgraded a .NET 4.7 project to .NET 6 in 3 days and haven’t touched it since. And the .NET project was larger. I haven’t done rails since that upgrade and I hope i never have to touch it again.

cjblomqvist 3y ago
Just to highlight; That's 6 major versions of .NET (so at least 7+ years in between). Including the Core era.

cultofmetatron 3y ago

come checkout phoenix. you get a lot of the same batterries included benefits of ror but the architecture is more moduler. runtime performance is closer to go-lang and there's a really fantastic websocket and reactive frontend system built in. Erlang OTP takes it a whole other level beyond that too if you're trying to scale up.

fredrikholm 3y ago
> runtime performance is closer to go-lang If you squint, yes. Erlang has had NIFs and ports since forever precisely because it isn't great at CPU intensive tasks. In most cases however, you're still looking at an order of magnitude less servers than the equivalent Rails/Django application.

pelasaco 3y ago

If you plan the updates since the beginning, and are up-to-date with what's coming next, you are good. Having the app dualboot, running it in your CI to catch upcoming changes is a easy way to avoid such headaches

stevebmark 3y ago
This is an ironic comment on a Shopify story, they have wasted a lot of time upgrading Rails https://shopify.engineering/upgrading-shopify-to-rails-5-0 https://shopify.engineering/upgrading-shopify-to-rails-5-0
- pelasaco 3y ago
  yeah people learned with time. Github had the same problem too.https://github.blog/2018-09-28-upgrading-github-from-rails-3-2-to-5-2/ https://github.blog/2018-09-28-upgrading-github-from-rails-3..... in 2023 it is so well documented, and so easy to automate, that shouldn't happen anymore.
  - stevebmark 3y ago
    It's not easy to automate. As you know Github now works directly off the Rails main branch. They have both core Ruby and core Rails maintainers on staff. They have to find, fix, approve, and merge, introduced bugs every day, as well as deal with Rails bugs themselves in the main branch that emerge. This is a huge overhead cost for keeping software up to date, and does not (and should not) apply to any other company.
    - pelasaco 3y ago
      guess what? 99% of the apps are not github, neither shopify. You add to your pipeline some automation with https://github.com/fastruby/next_rails https://github.com/fastruby/next_rails and you are done. I'm maintaing a rails app from 2006, with more than 1000 LC (excluding the 2k specs and views) and we are running on rails 7.1. We had one critical moment around rails 5.2 , but after that we managed to keep our stack always up to date.