Comment by P5fRxh5kUvp2th | Hacker News Reader

Comment by P5fRxh5kUvp2th | Hacker News Reader

Parent Full thread

A PCI auditor will ding the shit out of you for using a version of Angular that has known security vulnerabilities, even more so if you've decided to "vendor your project of choice" and it's been EoL'd.

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.

You seem to have more experience in PCI-related stuff so I won't comment on that. I'd like to focus on engineering point of view, not compliance matter.

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.

People like you keep me employed.

But you've snuck in another dependency there: that if the company uses Angular, they then have to have people familiar enough with the codebase of Angular itself that they can fix security bugs in it if they crop up. This is patently nontrivial, and a world away from having people internally who can fix bugs in...their internal framework...that they developed.

> This is patently nontrivial

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.

Reply on news.ycombinator.com