4 ms·

I had the same issue with Rails as I have with Node : the churn is detriment to long standing projects. Most projects I do run for years and even decades; you g

I had the same issue with Rails as I have with Node : the churn is detriment to long standing projects. Most projects I do run for years and even decades; you go run an update for security for Rails code that is 10 years old. It is a nightmare. I did not have issues like that with php, asp.net or spring.

chrischattin 6y ago
My experience has been the opposite. The Rails ecosystem makes updates straight forward and is very well documented. Been running various Rails apps for almost a decade now.
- dmurray 6y ago
  It's pretty good for incremental updates. It only asks a few hours a year to manage those. Not so good when you want to upgrade a 5-year-old system. I inherited a reasonably well-built Rails app deployed with Ruby 2.2.1 and would like to update it, if only for security reasons. I can't even run that on a recent Ubuntu. On a system where I can run it, I run into dependency hell with the gems - need to upgrade some, pin lower versions of others. Possibly that could have been handled with pinned dependency versions the first time round, but that breaks the regular upgrade process.
  - tluyben2 6y ago
    That is indeed what I meant; I had to create debootstraps to even get it running on my laptop. And many of the gem updates broke the apis completely for no reason (move fast and don’t care?) I do not know: I remember a security update where the new version renamed most of the api methods while there was no reason to do so. I understand you can add new methods to keep backward compat; here they actually renamed functions so it was not backwards compatible and you had to change everything. Simply put; we can cry about java or c# or php (raw php: not laravel; it has the same issues) but I can run 15 year old code on my current Ubuntu and it works fine. Maybe I need to change a few things but I do not have to rewrite a lot of it; it is more find/replace than anything. The feeling that software has to work in 50 years is important. Incremental updates are expensive and not needed for most companies, so software needs to support major version updates over decades. We know that now...
- Lammy 6y ago
  Straight-forward and documented is the minimum. Not having to think about it at all ever would be ideal. At some (huge) scale it will eventually become a thing that takes a year and a half and gets blog posts written about it, and I never enjoy losing a weekend to a microcosm of that: 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...
bob1029 6y ago
This is the primary reason why I love the .NET stack so much. Not only is a security update almost universally a non-event, but so are major framework revisions. Updating .NET applications for security concerns in many cases boils down to letting windows update do the thing it should already be doing automatically. In a much smaller portion of cases for .NET Core, a security update is a matter of rebuilding a self-contained deployment and pushing it out to production. Neither of these cases requires editing any code or configuration. Only in the transition from .NET Framework to .NET Core did we find any appreciable difficulty, and even then it was still within the realm of reasonable. Most of the pain here boiled down to usages of System.Drawing and DirectoryServices, both of which have alternatives that are supported on all platforms. We opted to use the compatibility pack instead, but would be OK if that was removed at some point and had to replace with the other implementations. We have lots of sourcecode that has withstood the test of time because of these technology choices. Many files are completely unchanged since .NET Framework 4.5 was released and now running flawlessly on top of .NET Core 3.1. This is the only reason we are still in business right now. I ended my journey with NodeJS (and AngularJS on the same day) when I attempted to update all of my packages after just a month of inactivity. Seeing the resulting pile of nonsensical dependency graph trash in my console may have radicalized me into using more "enterprisey" solutions when writing software that I might get put on pager duty for.
vinceguidry 6y ago
I loathe NodeJS with the passion of a thousand suns. When Rails projects churn, at least you can rely on the stability of Ruby. With Node, the number of times I had to work around inconsistencies with the framework and even language were maddening. Babel is a horrible horrible thing, and Javascript was never meant to run on a server. Maybe it's better now. But I won't ever do serious work again with the stack so I'll never find out.
- rybosworld 6y ago
  Node is getting better each year imo. I've been pretty happy with ES6. What makes you say Babel is horrible? Not disagreeing but I haven't heard anyone say that before.
  - jhardy54 6y ago
    I write JavaScript daily and my gripe with Babel (and transpilers in general) in the JS ecosystem is that it makes it easy to have 10 dependencies written in 10 similar-but-different languages. If you have to edit a dependency then you're stuck editing their source file (written in ES6-ES11 plus random unaccepted proposals / TypeScript / Coffeescript / Purescript / etc), installing their devDeps tree to run their build process, integrating their sourcemaps to un-break your stack traces, and writing code in a slightly different language each time you make a change. It's exhausting. It's really neat that we have the option to transpile, and I was actively working on transpilers in the Meteor ecosystem when they were all the rage, but at this point I try to avoid them whenever I can.
  - ratww 6y ago
    People don't say it directly, but all the constant complaining about the bloat and complexity of the JS ecosystem and the size of node_modules folder boils down mostly to two tools: Babel and Webpack.
    - tluyben2 6y ago
      But that is a sign is it not? If tools as badly designed as webpack is the standard, is that not saying there is an issue with the entire ecosystem?

chrischattin 6y ago

My experience has been the opposite. The Rails ecosystem makes updates straight forward and is very well documented. Been running various Rails apps for almost a decade now.

dmurray 6y ago
It's pretty good for incremental updates. It only asks a few hours a year to manage those. Not so good when you want to upgrade a 5-year-old system. I inherited a reasonably well-built Rails app deployed with Ruby 2.2.1 and would like to update it, if only for security reasons. I can't even run that on a recent Ubuntu. On a system where I can run it, I run into dependency hell with the gems - need to upgrade some, pin lower versions of others. Possibly that could have been handled with pinned dependency versions the first time round, but that breaks the regular upgrade process.
- tluyben2 6y ago
  That is indeed what I meant; I had to create debootstraps to even get it running on my laptop. And many of the gem updates broke the apis completely for no reason (move fast and don’t care?) I do not know: I remember a security update where the new version renamed most of the api methods while there was no reason to do so. I understand you can add new methods to keep backward compat; here they actually renamed functions so it was not backwards compatible and you had to change everything. Simply put; we can cry about java or c# or php (raw php: not laravel; it has the same issues) but I can run 15 year old code on my current Ubuntu and it works fine. Maybe I need to change a few things but I do not have to rewrite a lot of it; it is more find/replace than anything. The feeling that software has to work in 50 years is important. Incremental updates are expensive and not needed for most companies, so software needs to support major version updates over decades. We know that now...
Lammy 6y ago
Straight-forward and documented is the minimum. Not having to think about it at all ever would be ideal. At some (huge) scale it will eventually become a thing that takes a year and a half and gets blog posts written about it, and I never enjoy losing a weekend to a microcosm of that: 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...

bob1029 6y ago

This is the primary reason why I love the .NET stack so much. Not only is a security update almost universally a non-event, but so are major framework revisions. Updating .NET applications for security concerns in many cases boils down to letting windows update do the thing it should already be doing automatically. In a much smaller portion of cases for .NET Core, a security update is a matter of rebuilding a self-contained deployment and pushing it out to production. Neither of these cases requires editing any code or configuration. Only in the transition from .NET Framework to .NET Core did we find any appreciable difficulty, and even then it was still within the realm of reasonable. Most of the pain here boiled down to usages of System.Drawing and DirectoryServices, both of which have alternatives that are supported on all platforms. We opted to use the compatibility pack instead, but would be OK if that was removed at some point and had to replace with the other implementations. We have lots of sourcecode that has withstood the test of time because of these technology choices. Many files are completely unchanged since .NET Framework 4.5 was released and now running flawlessly on top of .NET Core 3.1. This is the only reason we are still in business right now. I ended my journey with NodeJS (and AngularJS on the same day) when I attempted to update all of my packages after just a month of inactivity. Seeing the resulting pile of nonsensical dependency graph trash in my console may have radicalized me into using more "enterprisey" solutions when writing software that I might get put on pager duty for.

vinceguidry 6y ago

I loathe NodeJS with the passion of a thousand suns. When Rails projects churn, at least you can rely on the stability of Ruby. With Node, the number of times I had to work around inconsistencies with the framework and even language were maddening. Babel is a horrible horrible thing, and Javascript was never meant to run on a server. Maybe it's better now. But I won't ever do serious work again with the stack so I'll never find out.

rybosworld 6y ago
Node is getting better each year imo. I've been pretty happy with ES6. What makes you say Babel is horrible? Not disagreeing but I haven't heard anyone say that before.
- jhardy54 6y ago
  I write JavaScript daily and my gripe with Babel (and transpilers in general) in the JS ecosystem is that it makes it easy to have 10 dependencies written in 10 similar-but-different languages. If you have to edit a dependency then you're stuck editing their source file (written in ES6-ES11 plus random unaccepted proposals / TypeScript / Coffeescript / Purescript / etc), installing their devDeps tree to run their build process, integrating their sourcemaps to un-break your stack traces, and writing code in a slightly different language each time you make a change. It's exhausting. It's really neat that we have the option to transpile, and I was actively working on transpilers in the Meteor ecosystem when they were all the rage, but at this point I try to avoid them whenever I can.
- ratww 6y ago
  People don't say it directly, but all the constant complaining about the bloat and complexity of the JS ecosystem and the size of node_modules folder boils down mostly to two tools: Babel and Webpack.
  - tluyben2 6y ago
    But that is a sign is it not? If tools as badly designed as webpack is the standard, is that not saying there is an issue with the entire ecosystem?