Moreover, I believe you should be able to build your project without expecting npm to host all your dependencies ~forever and being online when you need it.
And for good reason.
While you can theoretically do this, the point is that you really can't, nor would anyone call it responsible to do so even if they weren't worried about regulatory compliance.
The question isn't "can you keep it forever", the question is "how long can you keep it". With these frameworks that answer is typically 18-24 months. For more mature systems that answer is going to be 3-5 years, and for even more mature systems it's going to be 8-10.
FOR EXAMPLE
asp.net https://docs.microsoft.com/en-us/lifecycle/products/microsof... 2015-2022 = 7 years
Angular https://en.wikipedia.org/wiki/Angular_(web_framework)#Suppor...
2021-2022 = 1.5 years. And the status is LTS (LONG TERM SUPPORT).
But it gets even worse than that because the asp.net is worrying about the _runtime_, Angular is worrying about the _framework_. If we were going to compare apples-to-apples here, the support term for asp.net is even longer than 7 years.
---
The reason so many developers don't consider this is specifically because they move on every 18-24 months, and they're happy wasting time upgrading systems on the ratwheel. But businesses aren't, instead they're held hostage by it.
---
There's another thread on HN right now with people bitching about SAP. SAP will still run functions that were written 20 years ago.
Let's say a company's app has a security vulnerability. Let's consider 2 scenarios: (A) using Angular vs (B) using an internal framework.
From engineering perspective it doesn't matter if it's (A) or (B). It's not like the internal framework will be perfect and bug-free.
In both cases it is company's responsibility to patch their app. In case (A) they can fix it in their internal fork of Angular; or fix it upstream; or update Angular to an unaffected version. In case (B) they have to fix their framework.
You stated that:
> When a company decides to use Angular (for example), they're also deciding to jump on the rat-wheel that is constant upgrades to the next version.
> Meanwhile, that vanilla app will just keep working in perpetuity.
and I disagree with it.
If a company doesn't care about security, they can have Angular "working in perpetuity" as well as their vanilla app.
If they do care about security, their vanilla app will not (securely) "work in perpetuity" since it will need a fix sooner or later.
Exactly. I can walk a new developer through most of our internal framework's actual source code in about 30-45 minutes. If you told me I had to explain the inner workings of Angular to some new hire, I may consider a new career path.