4 ms·

The same reasoning applies. Don't upgrade if you don't need the new features.

Spivak 2y ago
If your answer to how to make it stable is never update (including your dependencies) then you're not working on a stable technology. Stable is being able to set up unattended upgrades on Ubuntu LTS fearlessly. When was the last time you worried about your kernel update?
- root_axis 2y ago
  > If your answer to how to make it stable is never update then you're not working on a stable technology. I didn't say "never update", I said that if you don't need the new features then don't upgrade. If you do need the new features then I don't understand what the problem is. > Stable is being able to set up unattended upgrades on Ubuntu fearlessly. lol what? I've never had a system survive an Ubuntu upgrade without breaking something.
  - netdevnet 2y ago
    Point is many of these libraries don't just let you get latest without rewriting some of your code. Multiple that by 10-20 and you are in for a real treat.
    - root_axis 2y ago
      > Point is many of these libraries don't just let you get latest without rewriting some of your code. True of every software platform in existence. On the scale of upgrade complexity, react is a walk in the park compared to e.g. everything in the android and ios world, or e.g. any application written for a desktop platform. Ever tried upgrading a C++ app? It's a nightmare beyond anything I've ever faced in my career. I've never worked with Rust in a professional environment, but I've been a big fan of it for my personal projects for some years now, however, the introduction of async was a massive disruption to the entire ecosystem. In my opinion, complaining about JS complexity in particular reflects ignorance of the wider software world.
      - Spivak 2y ago
        Well yeah but Rust isn't a boring technology and C++ has its own reasons for being difficult. The goto examples of boring are C (and Objective-C), Java, Perl 5, PHP, Vanilla JS (the browser itself is remarkably stable), Rails, Django. Just a who's who of ecosystems people don't want to program in. Perl code doesn't work today just as well as it didn't work 20 years ago.
    - Spivak 2y ago
      Yep patching Ubuntu is so stable it's fully automatic and upgrading to the latest Ubuntu is 1-2 days work. Getting to the latest on our front end is a project.
netdevnet 2y ago
I don't know in what company you work at. But you can't have outdated libraries in production forever. Vulnerabilities happen. Stable does not equate outdated. Look at .Net. You can pick a codebase from 2014 and make your way around easily. It is like home. Similarly, your 2014 dev could jump into a time machine into 2024 and work with .Net Core easily. Also, 2014 codebase can keep getting the latest security patches without having to rewrite the codebase. That's not the case with React or most of the js frameworks
- root_axis 2y ago
  > Look at .Net. .net??? I worked with .net for about 10 years and over multiple versions of .net and .net core, the amount of time we spent facilitating upgrades was much more than I ever spent on upgrading a react app. In fact, at my last .net job I was hired specifically to transition the company's platform from .net to .net core. There was so much work involved that they literally created a role for it.
  - netdevnet 2y ago
    > I was hired specifically to transition the company's platform from .net to .net core I can see this being the case if the codebase wasn't in a good state which is a problem of its own. But with proper separation layers. There is not much you have to update in a net framework 472 library project to move it to a net core library project which should contain most of your logic and be tech agnostic anyway. Most of the work is likely to be in the technology dependent projects (web projects and that kind). The common language features remain virtually unchanged. In a front-end project this is much harder, as that kind of abstraction is much harder to come across as the language and technology are tightly coupled. In an ideal world, your component logic is tech agnostic and should work unchanged in React, Angular, Vue, etc. But in real life, you write your logic using the relevant tech and then when that tech breaks some keyword or how to do x, your app breaks in 50 components and you have to go and make the change manually in all those 50 components.

If your answer to how to make it stable is never update (including your dependencies) then you're not working on a stable technology. Stable is being able to set up unattended upgrades on Ubuntu LTS fearlessly. When was the last time you worried about your kernel update?

root_axis 2y ago
> If your answer to how to make it stable is never update then you're not working on a stable technology. I didn't say "never update", I said that if you don't need the new features then don't upgrade. If you do need the new features then I don't understand what the problem is. > Stable is being able to set up unattended upgrades on Ubuntu fearlessly. lol what? I've never had a system survive an Ubuntu upgrade without breaking something.
- netdevnet 2y ago
  Point is many of these libraries don't just let you get latest without rewriting some of your code. Multiple that by 10-20 and you are in for a real treat.
  - root_axis 2y ago
    > Point is many of these libraries don't just let you get latest without rewriting some of your code. True of every software platform in existence. On the scale of upgrade complexity, react is a walk in the park compared to e.g. everything in the android and ios world, or e.g. any application written for a desktop platform. Ever tried upgrading a C++ app? It's a nightmare beyond anything I've ever faced in my career. I've never worked with Rust in a professional environment, but I've been a big fan of it for my personal projects for some years now, however, the introduction of async was a massive disruption to the entire ecosystem. In my opinion, complaining about JS complexity in particular reflects ignorance of the wider software world.
    - Spivak 2y ago
      Well yeah but Rust isn't a boring technology and C++ has its own reasons for being difficult. The goto examples of boring are C (and Objective-C), Java, Perl 5, PHP, Vanilla JS (the browser itself is remarkably stable), Rails, Django. Just a who's who of ecosystems people don't want to program in. Perl code doesn't work today just as well as it didn't work 20 years ago.
  - Spivak 2y ago
    Yep patching Ubuntu is so stable it's fully automatic and upgrading to the latest Ubuntu is 1-2 days work. Getting to the latest on our front end is a project.

netdevnet 2y ago

I don't know in what company you work at. But you can't have outdated libraries in production forever. Vulnerabilities happen. Stable does not equate outdated. Look at .Net. You can pick a codebase from 2014 and make your way around easily. It is like home. Similarly, your 2014 dev could jump into a time machine into 2024 and work with .Net Core easily. Also, 2014 codebase can keep getting the latest security patches without having to rewrite the codebase. That's not the case with React or most of the js frameworks

root_axis 2y ago
> Look at .Net. .net??? I worked with .net for about 10 years and over multiple versions of .net and .net core, the amount of time we spent facilitating upgrades was much more than I ever spent on upgrading a react app. In fact, at my last .net job I was hired specifically to transition the company's platform from .net to .net core. There was so much work involved that they literally created a role for it.
- netdevnet 2y ago
  > I was hired specifically to transition the company's platform from .net to .net core I can see this being the case if the codebase wasn't in a good state which is a problem of its own. But with proper separation layers. There is not much you have to update in a net framework 472 library project to move it to a net core library project which should contain most of your logic and be tech agnostic anyway. Most of the work is likely to be in the technology dependent projects (web projects and that kind). The common language features remain virtually unchanged. In a front-end project this is much harder, as that kind of abstraction is much harder to come across as the language and technology are tightly coupled. In an ideal world, your component logic is tech agnostic and should work unchanged in React, Angular, Vue, etc. But in real life, you write your logic using the relevant tech and then when that tech breaks some keyword or how to do x, your app breaks in 50 components and you have to go and make the change manually in all those 50 components.