6 ms·

Im pretty sure that most packages and frameworks break less than your own code…

by jwpapi 1y ago

bravesoul2 1y ago
I think the issue is API breakage. Does your 5 year old NextJS project still work after npm update? Probably not! What about your simple Go server or FastAPI server. Probably yes.
- victorbjorklund 1y ago
  So don't run npm updates because sure then you have the security risks that you have some old code and that is five years old and hasn't been worked on for five years and you also have you missing out on new functions and optimizations. However if you have a five-year-old project that you handwritten everything by yourself you probably have a lot of security issues there too assuming that you are using complicated functions like you would have in Next.js. So then you would have to update a lot more than you would need to bring an old Next.js project up to date. You would need to rewrite all your code from scratch almost.
  - bravesoul2 1y ago
    Yes run updates of course. The question is how much of a headache you want. You can: Use Next.js (frequently changing lots of transitive deps, suffers from Node ecosystem churn too) Roll your own framework OR (FANFARE....) Use simpler arguably more professional tools. That 10 year old .NET MVC site. Guess what. Still works. Still secure.
    - threetonesun 1y ago
      10 year old .NET is running on a Windows server that, I hope, you've done some security updates on. Having worked on most web facing stacks out there that might have been the worst one you could have picked as a "future proof" deployment, unless you're comparing them all as something you release once and then never touch again.
      - jimnotgym 1y ago
        But did running Windows Update ever break the website?
        bravesoul2 1y ago
        Indeed. And did it require a Jira ticket to rearchitecture the app.
    - victorbjorklund 1y ago
      guess it depends on def of framework. I would say using .net mvc is a framework.
  - d0gsg0w00f 1y ago
    Are you saying that because you have to touch it all the time, you're sure it's up to date? I suppose that's one way to look at it.
- raincole 1y ago
  > npm update Patient: Doctor, it hurts when I do this. Doctor: Don't do this than.
- codeptualize 1y ago
  Any decent sized project will encounter breaking changes in dependencies. The big frontend frameworks have great backward compatibility and usually provide codemods that automatically update your project. If you install UI components and other libraries that might get abandoned or have breaking changes in major version updates you might have to put in more effort, that's not different in Go or Python.
- 0cf8612b2e1e 1y ago
  Seeing as how FastAPI is only six years old, not sure that works as a great example. One of those projects which has never released a 1.0, so not comforting on backwards compatibility.
aktuel 1y ago
My own code doesn't break without me working on it.
- bapak 1y ago
  Correct. It's broken by default because you're the only user and worked on it for 10 minutes 5 years ago. Probably wrote no tests for it. Compare that to something like jQuery where all the edge cases have already been accounted for 10 years ago.
  - namenotrequired 1y ago
    If I worked on it for 10 minutes 5 years ago then it’s definitely not taking lots of time and energy
    - bapak 1y ago
      As far as you know. People who don't "over engineer" also don't track errors. So you might be losing a bunch of users because your website is broken on their devices, and you'll never know. You can't repro it because your locale doesn't match theirs.
- iLoveOncall 1y ago
  Neither do your dependencies. Unless the maintainer somehow hacks into your server and updates them for you?
  - brabel 1y ago
    People in web development tend to allow dependencies to auto-update. It’s kind of a necessary evil in that the alternative is to do it only manually and then falling behind on security vulnerabilities updates and potentially getting hacked.
    - victorbjorklund 1y ago
      But by that argument, if you try to write all of the code doing the functions just by yourself and not bring in any dependencies, and that code is now five years old and you haven't touched it for five years, you might have some security vulnerabilities too. It's not like you are always writing better code than the open source projects are. Unless you are one of the best developers in the world, then sure, then that might work, but for the rest of us, we are probably not guaranteed to ever write code that is 100% bug free for five years.
Bigpet 1y ago
You can math that out pretty well. If your code has a breakage chance of 50% and your dependencies all have a breakage chance of 1% then with 70 dependecies you get to 50.5% breakage chance from dependencies.

Im pretty sure that most packages and frameworks break less than your own code…

by jwpapi 1y ago

Im pretty sure that most packages and frameworks break less than your own code…

I think the issue is API breakage. Does your 5 year old NextJS project still work after npm update? Probably not! What about your simple Go server or FastAPI server. Probably yes.

victorbjorklund 1y ago
So don't run npm updates because sure then you have the security risks that you have some old code and that is five years old and hasn't been worked on for five years and you also have you missing out on new functions and optimizations. However if you have a five-year-old project that you handwritten everything by yourself you probably have a lot of security issues there too assuming that you are using complicated functions like you would have in Next.js. So then you would have to update a lot more than you would need to bring an old Next.js project up to date. You would need to rewrite all your code from scratch almost.
- bravesoul2 1y ago
  Yes run updates of course. The question is how much of a headache you want. You can: Use Next.js (frequently changing lots of transitive deps, suffers from Node ecosystem churn too) Roll your own framework OR (FANFARE....) Use simpler arguably more professional tools. That 10 year old .NET MVC site. Guess what. Still works. Still secure.
  - threetonesun 1y ago
    10 year old .NET is running on a Windows server that, I hope, you've done some security updates on. Having worked on most web facing stacks out there that might have been the worst one you could have picked as a "future proof" deployment, unless you're comparing them all as something you release once and then never touch again.
    - jimnotgym 1y ago
      But did running Windows Update ever break the website?
      - bravesoul2 1y ago
        Indeed. And did it require a Jira ticket to rearchitecture the app.
  - victorbjorklund 1y ago
    guess it depends on def of framework. I would say using .net mvc is a framework.
- d0gsg0w00f 1y ago
  Are you saying that because you have to touch it all the time, you're sure it's up to date? I suppose that's one way to look at it.
raincole 1y ago
> npm update Patient: Doctor, it hurts when I do this. Doctor: Don't do this than.
codeptualize 1y ago
Any decent sized project will encounter breaking changes in dependencies. The big frontend frameworks have great backward compatibility and usually provide codemods that automatically update your project. If you install UI components and other libraries that might get abandoned or have breaking changes in major version updates you might have to put in more effort, that's not different in Go or Python.
0cf8612b2e1e 1y ago
Seeing as how FastAPI is only six years old, not sure that works as a great example. One of those projects which has never released a 1.0, so not comforting on backwards compatibility.

aktuel 1y ago

My own code doesn't break without me working on it.

bapak 1y ago
Correct. It's broken by default because you're the only user and worked on it for 10 minutes 5 years ago. Probably wrote no tests for it. Compare that to something like jQuery where all the edge cases have already been accounted for 10 years ago.
- namenotrequired 1y ago
  If I worked on it for 10 minutes 5 years ago then it’s definitely not taking lots of time and energy
  - bapak 1y ago
    As far as you know. People who don't "over engineer" also don't track errors. So you might be losing a bunch of users because your website is broken on their devices, and you'll never know. You can't repro it because your locale doesn't match theirs.
iLoveOncall 1y ago
Neither do your dependencies. Unless the maintainer somehow hacks into your server and updates them for you?
- brabel 1y ago
  People in web development tend to allow dependencies to auto-update. It’s kind of a necessary evil in that the alternative is to do it only manually and then falling behind on security vulnerabilities updates and potentially getting hacked.
  - victorbjorklund 1y ago
    But by that argument, if you try to write all of the code doing the functions just by yourself and not bring in any dependencies, and that code is now five years old and you haven't touched it for five years, you might have some security vulnerabilities too. It's not like you are always writing better code than the open source projects are. Unless you are one of the best developers in the world, then sure, then that might work, but for the rest of us, we are probably not guaranteed to ever write code that is 100% bug free for five years.

Bigpet 1y ago

You can math that out pretty well. If your code has a breakage chance of 50% and your dependencies all have a breakage chance of 1% then with 70 dependecies you get to 50.5% breakage chance from dependencies.