If there are no security problems affecting your project, and you don't benefit from new features, there is no urge to update. And even then, it's a cost/benefit ratio.
Updating is a constraint, one you follow either because it solves a problem or avoid a pitfall, not a goal.
I migrated most of my stuff to Python 3 years ago, but for some of my clients, despite that 2.7 is not supported anymore, I advice to just download a copy of everything they need offline as a safety measure and keep the system running as-is forever.
Raw HTML + jQuery + Django 1.x + VPS still deliver fine. Just because I can do react + microservices does not mean it should be a default response.
There are servers running barely touched from one or two decades ago and they do their job perfectly.
So yes, some client side libs are going to be there for years and years. If the UI works, it's alright.
Software is not an end, it's a tool. Being passionate about it, it's easy to forget that, but we use software to help the real world, not the other way around.
Not saying of course you should never update nor use modern technology when appropriate: technical debt must be paid. But it's important to recognize when you need to do it, and when you just want a shiny toy or to look good.
This applies to libraries installed using <script src="://cdnjs.com/path-to-lib.js">. Most cdns have a 'latest' path but using that can result in your site breaking when a dependency changes. Web developers need to stop taking the lazy option and test more.
JS libraries installed using npm to be bundled in are pinned to the major version, so they usally update to the latest minor or patch whenever the thing is deployed. That's still a problem because it only works if an app is actively maintained and deployed regularly, but it's better than nothing.
It is a myth that all websites (or applications) have an active development team continuously deploying updates. I would even expect that the vast majority of the code in production in the world is old code that is not looked after. This is particularly true for small non-tech companies that outsourced the development, and for internal systems in large organisations where the developers have been re-assigned to other projects.
This is why technologies that assume active development, like containers, cloud APIs, etc are in my opinion a disaster in the making.
It needs to work more like libraries on Linux. They have an API, the api _may_ expand, but will never, ever, change or break without a major version rev.
Then for that stable API a URL could target the latest version that fulfills it.
I never understood the need (desire) to update your dependencies as much and often as possible. As long as a project builds and runs without any issues, why put effort in upgrading libraries and exposing yourself to possible issues.
The main reason is security. When a security vulnerability is patched in a new version of one of the libraries you use, you should upgrade, and if you haven't upgraded it in two years it is gonna be a pain in the ass.
On one of our projects we've got what I think is the best take on this I've seen. Once a week, CI updates all our dependencies and makes fresh PR. That PR then goes through CI and can be merged by an engineer if it looks good.
> why put effort in upgrading libraries and exposing yourself to possible issues.
Isn't this what the combination of a "package manager" with semantic versioning scheme actually should automate?
Personally, I think this is where NPM failed and still fails. They should enforce a binary format that ships with header files (and method signatures), and enforce semantic versioning.
If any library doesn't play by the semantic rules, don't let it publish. That's the authority and responsibility that NPM failed to include.
If everybody plays by the semantic rules ... then libraries can be upgraded automatically without breaking anything. And a huge plus: They can be installed as _shared_ libraries, which is such an old concept that it hurts my fingers having to type its advantages.
I always update libraries when I'm revisiting a project. This help me to engage with the project because the thing that motivates me most is if something doesn't work. And after updating libraries something usually doesn't.
I get where you're coming from, however, I think having an update cycle, even if it's something like once in 18 months, is important, especially as a responsibility one has to their project's successors.
There's nothing worse than coming to a project riddled with deprecation warnings and when one tries to update, breaking changes in libraries result in a ton of issues.
Also, it can (and most likely will at some point) affect your release dates when unexpected issues arise due to deprecated APIs.
Because it is a major security issue to not keep up with library upgrades and general maintenance. It's in the OWASP top 10 for a reason. The Equifax breach is a perfect example of why ignoring library upgrades is a high risk behavior for any organization.
Security and availability. If you’re at a large company, not updating your dependencies could mean an outage, losing customer or other data you don’t want exposed to the world.
A simpler way to state it is it could be the death of your company.
"JavaScript Libraries Are Almost Never Updated Once Installed"
...on an website.
I imagine the ease with which one can type `npm i` or `yarn install` means that server-side JavaScript libraries are updated frequently. Wasn't that the whole problem with that leftpad thing?
Out of curiosity I went to look for the most frequently downloaded (installed) library on npm, which apparently is not directly available, but here's a pretty arbitrary selection of things that came to mind:
* express - last release 8 months - 11.4m downloads this week
* React (which is pretty browser-oriented, right?) - last release 3 months ago - 6.5m downloads this week
* Underscore - last release 1 month ago - 6.7m downloads this week
* jquery (almost exclusively browser-oriented, certainly DOM oriented) - last release 9 mos ago - 3.1m downloads this week
It seems like someone must be keeping up-to-date.
Also "installed" is a misleading statement in the web context, JavsScript libraries aren't _installed_ they are _integrated_ with the site, which means an upgrade isn't free, it's a semi-new integration effort.
I try to run `npm-check -u` at least once a week. It takes some time when a dependency has a breaking change or a project that I don't trust to respect semantic versioning is updated and I have to check its git diff, but in practice my projects have up to date dependencies without much efforts.
[+] [-] BiteCode_dev|6 years ago|reply
Updating is a constraint, one you follow either because it solves a problem or avoid a pitfall, not a goal.
I migrated most of my stuff to Python 3 years ago, but for some of my clients, despite that 2.7 is not supported anymore, I advice to just download a copy of everything they need offline as a safety measure and keep the system running as-is forever.
Raw HTML + jQuery + Django 1.x + VPS still deliver fine. Just because I can do react + microservices does not mean it should be a default response.
There are servers running barely touched from one or two decades ago and they do their job perfectly.
So yes, some client side libs are going to be there for years and years. If the UI works, it's alright.
Software is not an end, it's a tool. Being passionate about it, it's easy to forget that, but we use software to help the real world, not the other way around.
Not saying of course you should never update nor use modern technology when appropriate: technical debt must be paid. But it's important to recognize when you need to do it, and when you just want a shiny toy or to look good.
[+] [-] onion2k|6 years ago|reply
JS libraries installed using npm to be bundled in are pinned to the major version, so they usally update to the latest minor or patch whenever the thing is deployed. That's still a problem because it only works if an app is actively maintained and deployed regularly, but it's better than nothing.
[+] [-] cm2187|6 years ago|reply
This is why technologies that assume active development, like containers, cloud APIs, etc are in my opinion a disaster in the making.
[+] [-] mschuster91|6 years ago|reply
Who is going to pay for that? Most customers want a "fire and forget" experience, no ongoing maintenance budgets. Same for hobbyist projects.
[+] [-] mjevans|6 years ago|reply
Then for that stable API a URL could target the latest version that fulfills it.
src="://cdnjs.com/some/path/latest-API3.js"
[+] [-] karimmaassen|6 years ago|reply
[+] [-] macrael|6 years ago|reply
On one of our projects we've got what I think is the best take on this I've seen. Once a week, CI updates all our dependencies and makes fresh PR. That PR then goes through CI and can be merged by an engineer if it looks good.
[+] [-] cookiengineer|6 years ago|reply
Isn't this what the combination of a "package manager" with semantic versioning scheme actually should automate?
Personally, I think this is where NPM failed and still fails. They should enforce a binary format that ships with header files (and method signatures), and enforce semantic versioning.
If any library doesn't play by the semantic rules, don't let it publish. That's the authority and responsibility that NPM failed to include.
If everybody plays by the semantic rules ... then libraries can be upgraded automatically without breaking anything. And a huge plus: They can be installed as _shared_ libraries, which is such an old concept that it hurts my fingers having to type its advantages.
[+] [-] scotty79|6 years ago|reply
[+] [-] bdg|6 years ago|reply
The entire security thing.
Not getting "free value" of performance fixes, bug fixes, new features, etc.
[+] [-] toyg|6 years ago|reply
[+] [-] r_singh|6 years ago|reply
There's nothing worse than coming to a project riddled with deprecation warnings and when one tries to update, breaking changes in libraries result in a ton of issues.
Also, it can (and most likely will at some point) affect your release dates when unexpected issues arise due to deprecated APIs.
[+] [-] codebje|6 years ago|reply
[+] [-] knightofmars|6 years ago|reply
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top...
[+] [-] tracer4201|6 years ago|reply
A simpler way to state it is it could be the death of your company.
[+] [-] rodw|6 years ago|reply
...on an website.
I imagine the ease with which one can type `npm i` or `yarn install` means that server-side JavaScript libraries are updated frequently. Wasn't that the whole problem with that leftpad thing?
Out of curiosity I went to look for the most frequently downloaded (installed) library on npm, which apparently is not directly available, but here's a pretty arbitrary selection of things that came to mind:
* express - last release 8 months - 11.4m downloads this week
* React (which is pretty browser-oriented, right?) - last release 3 months ago - 6.5m downloads this week
* Underscore - last release 1 month ago - 6.7m downloads this week
* jquery (almost exclusively browser-oriented, certainly DOM oriented) - last release 9 mos ago - 3.1m downloads this week
It seems like someone must be keeping up-to-date.
Also "installed" is a misleading statement in the web context, JavsScript libraries aren't _installed_ they are _integrated_ with the site, which means an upgrade isn't free, it's a semi-new integration effort.
[+] [-] FloatArtifact|6 years ago|reply
[+] [-] speedgoose|6 years ago|reply
[+] [-] rmist|6 years ago|reply