Hacker News Reader

Comment by jwpapi | Hacker News Reader

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.

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.

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.

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.

But did running Windows Update ever break the website?

Indeed. And did it require a Jira ticket to rearchitecture the app.

guess it depends on def of framework. I would say using .net mvc is a framework.

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.

> npm update

Patient: Doctor, it hurts when I do this.

Doctor: Don't do this than.

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.

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.

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

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.

If I worked on it for 10 minutes 5 years ago then it’s definitely not taking lots of time and energy

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.

Neither do your dependencies. Unless the maintainer somehow hacks into your server and updates them for you?

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.

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.

> and that code is now five years old and you haven't touched it for five years, you might have some security vulnerabilities too

Security vulnerabilities grow in unattended code then?

Or they were there from the second the code was written but with some luck someone noticed them and fixed them?

Old code isn't necessarily insecure just because it's old...

Doesnt matter if you count them from the second the code is written or when they are discovered. The same issue is in code written by someone else or yourself.

The point is that freshly updated code has the same chance of being buggy.

You want me to believe that in the npm "ecosystem" they have LTS branches that only get security updates? For anything besides maybe a few large libraries with companies behind them?

While ironically leaving themselves open to supply chain attacks.

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.

Reply on news.ycombinator.com