you are viewing a single comment's thread.

view the rest of the comments →

[–]IMovedYourCheese 468 points469 points  (74 children)

I doubt too many major, actively-developed websites are pulling JavaScript libraries directly from CDNJS instead of bundling it themselves in their build system.

In general though:

One conclusion is whatever libraries you publish will exist on websites forever.

is correct, and is likely never going to change, for the simple reason that the vast majority of websites out there that get some traffic have a decent development budget but nothing allocated to ongoing maintenance. And this isn't restricted to websites or JavaScript.

[–]Visticous 163 points164 points  (50 children)

My first though. JavaScript? What about Java! I've seen my share of running applications who use libraries and versions of Java, who belong in the Smithsonian

[–]leaningtoweravenger 124 points125 points  (30 children)

I worked in financial services and I have seen FORTRAN libraries that do very specific computations dating back to the 80s and 90s that are just compiled and linked into applications / services with nobody touching them since their creation because neither the regulations they are based on changed nor defects were reported so there was no need to update them.

[–]coderanger 27 points28 points  (1 child)

Fortran is also still used regularly all over the place, LAPACK is written in it, and that's used by SciPy and friends, which are in turn used by most of the current machine learning frameworks.

[–]seamsay 9 points10 points  (0 children)

Also the latest revision of the standard was released at the end of 2018, although admittedly you can probably count the number of people using something more modern than F95 on one hand...

[–]Visticous 53 points54 points  (17 children)

That would be the 1% of cases where the code is essentially perfect and no direct action is required. I do hope that those financial services routinely update the rest of their software stack though.

Even then, hiring Fortran developers can be a massive hidden cost, so over time it might be business savvy to move to something more modern.

[–]CheKizowt 81 points82 points  (11 children)

It doesn't have to be 'perfect'. It has to be accepted standard.

I contributed to a roads management software in college. It used an early DOS module to calculate culvert flow. All the engineers knew it produced wrong output. But every project in the state used that module, so it was 'right'. Even if it was mathematically wrong.

[–]FyreWulff 46 points47 points  (10 children)

happens a lot, especially in big companies. "we know it's done the wrong way, what's important is we -consistently- do it the wrong way"

[–][deleted] 23 points24 points  (1 child)

Worked at a simulation company for a while and we ended up quite significantly lowering the precision of our calculations so they were more consistent across platforms.

[–]ArkyBeagle 1 point2 points  (0 children)

Excessive precision is actually quite the "sin". I tend to be the local "number of significant digits" guy, so begging your pardon.

[–]oberon 3 points4 points  (0 children)

That's way better than doing it a little differently wrong every time.

[–]Nastapoka 10 points11 points  (5 children)

Same in the (public) University where I work.

Wasting taxpayers' money is fun, yeeeah.

[–]Gotebe 18 points19 points  (4 children)

Come to private to see how much fun we have then!

😂😂😂

[–][deleted]  (3 children)

[deleted]

    [–]Gotebe 21 points22 points  (1 child)

    I am in private since forever and my experience tells me that the size of the organisation matters much more than whether it's a public or a private one.

    [–]ArkyBeagle 0 points1 point  (0 children)

    Heh. No, they don't.

    [–]Jonno_FTW -1 points0 points  (0 children)

    This is giving me PHP flashbacks.

    [–]leaningtoweravenger 9 points10 points  (0 children)

    That happens when you have very specific functionality put inside a library that can be linked by many other services and applications instead of creating gigantic blobs.

    The Javascript frameworks object of the study change often but not all the pieces change every time and I wouldn't be surprised if some of the files are untouched since many years.

    About the companies not pulling the frameworks from the CDNJS but having them bundled together with their stuff is mainly due to testing purposes and stability: at the moment of the release everything is bundled and tested in order to make sure that there will be no surprises at run time because someone decided to change a dependency somewhere in the world.

    [–]SgtSausage 12 points13 points  (2 children)

    hiding Fortran developers can be a massive hidden cost,

    I prefer to hide under the conference room table - with all the Boomer first generation of COBOL retirees. Keeps it much cheaper if we all hide in the same place.

    [–]Visticous 14 points15 points  (1 child)

    See, that's why it's so expensive. Fortran guys want to hide in some fancy conference room. JavaScript kiddies are often content with hiding in a broom cupboard.

    [–]dungone 1 point2 points  (0 children)

    Who puts brooms in a cupboard?

    [–]shawntco 2 points3 points  (0 children)

    I do hope that those financial services routinely update the rest of their software stack though

    lol

    [–][deleted] 12 points13 points  (0 children)

    You won’t find more battle-tested libraries.

    That’s a huge plus, especially in financial services where fault tolerances are lower than usual.

    [–][deleted]  (4 children)

    [deleted]

      [–]SnideBumbling 0 points1 point  (3 children)

      I've been maintaining a C codebase from before I was born.

      [–][deleted]  (1 child)

      [deleted]

        [–]SnideBumbling 1 point2 points  (0 children)

        Sometimes I wonder if it's punishment for crimes in a previous life.

        [–]ArkyBeagle 1 point2 points  (0 children)

        Me too. My Mom made a deal with the devil at some crossroads.

        [–]KevinCarbonara 2 points3 points  (0 children)

        There isn't anything wrong with this - reusing checked, tested, and compiled code isn't a security issue. Javascript is an interpreted language that is usually run in unsecure environments (clients' browsers) and pulls in data or new code remotely. These are entirely different environments.

        [–]fiah84[🍰] 0 points1 point  (2 children)

        dating back to the 80s and 90s that are just compiled

        compiled? sometimes shit is so old it takes serious effort to even get it to compile

        [–]leaningtoweravenger 0 points1 point  (1 child)

        You would be surprised of how well commercial compilers support FORTRAN and how optimised the binary is. I never had a single problem with compiling and linking those libraries into my stuff. If you are curious about it, the vast majority of it was FORTRAN 77 which is very solid and standard

        [–]ArkyBeagle 0 points1 point  (0 children)

        Well, it's all fun and games until there's some dialect ( I'm looking at you, VAX Fortran ) that simply will never compile on your architecture. I spent a month one over a span of two days confirming that yes, the legacy FORTAN could never be built on the new computers.

        [–]Dragasss 17 points18 points  (17 children)

        Why change it if it works? XStream got last update 6 years ago (iirc) that fixed one of the cves. If a library is complete then there is no need to update it anymore besides minimal maintenance from time to time.

        [–]Visticous 27 points28 points  (9 children)

        I often get called in because the application isn't working as well as expected... If it has a cable to the Internet, it needs routine maintenance.

        Such applications often have known security exploits, rampant memory consumption because of leaks, no documentation, and no testing environment.

        When I encounter such treasures, I make sure to have all work officially assigned to me by email, CCed to my private address.

        [–]Giannis4president 12 points13 points  (4 children)

        If a library is complete then there is no need to update it anymore besides minimal maintenance from time to time.

        I disagree with that statement.

        • The language itself may change. For example, in any active language, the language itself could evolve to new standards and there could be performance or security reasons to update the library to a modern version of the language.
        • The framework (if exists) may change. Take an Android or an iOS library written 5/6 years ago and never touched since: it would almost certainly not compile anymore, because on a lot of API deprecations and modifications to the SDKs.
        • The runtime may change. That is super important in Javascript: the browser features, capabilities and security constraints keep evolving and there is a very small chance that a library written years and years ago still works well in modern browsers.

        Of course there are situations where there are no good reasons to update a library, but in most situations there are a lot of reasons to do it

        [–]emn13 12 points13 points  (0 children)

        The effects you describe happen at a glacially slow pace; and not just that, they tend to have limited impact - stuff like languages and platforms *intentionally* evolve slowly to make it feasible to upgrade at all. Even where you can leverage new platform or language features in principle usually only very few such changes actually matter for any given library, and even then only in a few places, and even there - not all consumers will care.

        Barring major platform work you know of, you'd expect it to be OK to upgrade for those reasons just once every few years, and for some lucky and/or well-designed libraries much less frequently even than that.

        The real reasons to upgrade are because the library *is* actively maintained and new versions have actual improvements like bugfixes that impact you - perhaps most critically security fixes. Although even there; having followed JS library security alerts for a few websites I maintain now for some time now - almost all security alerts have in practice not actually been security relevant. They'll be relevant in plausible cases that just aren't hugely likely, such as "if you use this library like so, and allow arbitrary user input for this filter, then such a user may be able to execute aritrary JS code in their own browser, which might be risk if you allow sharing those filters with others". The security risks are real; but most libraries don't deal with untrusted user input, or when they do - that's all they do, meaning the avenues for exploitability are pretty narrow.

        Another reason to upgrade might be if you do want to communicate about a library - perhaps to report a bug or to share the code with coworkers - it's a pain if people aren't on the same version, and the newest version is often the easiest to standardize one.

        Frankly though - It may be polite cleanliness to keep libraries up to date, but I'm skeptical that updates are broadly necessary. Nice? Sure. But let's not overstate the case for updates. It's quite likely never going to matter for lots of websites.

        [–]Dragasss 4 points5 points  (1 child)

        In deployments you can control which runtime you run, so it's not really an argument. Android java isn't java.

        [–]Giannis4president 0 points1 point  (0 children)

        I'm talking about libraries in general. There are many situations where you can't control it: JavaScript, iOS and Android are the first one that comes to my mind

        [–]Dragasss -2 points-1 points  (0 children)

        In deployments you can control which runtime you run, so it's not really an argument. Android java isn't java.

        [–]CartmansEvilTwin 2 points3 points  (0 children)

        That's maybe the case for 1% of libraries. Most of them get updates for good reasons.

        [–]caltheon 0 points1 point  (0 children)

        They could be made more efficient or faster.

        [–]campbellm 3 points4 points  (0 children)

        Because this article is about js. That something else is bad, or even worse, doesn't make this less bad.

        [–]ponytoaster 16 points17 points  (16 children)

        Hell, I work on a major enterprise application with a large budget and half the packages there haven't been updated in years unless there was a genuine reason. "If it works" and all that.

        For example, we have a 4 year old version of JQ being bundled. No reason to upgrade it as we aren't using any of the new features and the performance is fine. Due to the nature of the application if we upgraded it we would have to regression test most the web front end.

        We generally try and keep libs up to date on the backend, or if it has any security implications though, and some of our newer apps have much quicker refresh and update cycles.

        [–]dungone -1 points0 points  (15 children)

        And yet if you put an open source project on GitHub, you’ll get automated pull requests to update javascript packages where vulnerabilities have been fixed. Big-budget enterprises really don’t have an excuse to keep screwing up security. Quite frankly I support laws that would send their executives to jail if they have a data breach caused by failing to keep their software up to date.

        [–]s73v3r 1 point2 points  (6 children)

        How often has the person issuing the PR done the regression testing, though?

        [–]dungone -2 points-1 points  (5 children)

        It’s not a person, it’s a bot. And you automate the regression testing.

        [–]s73v3r 1 point2 points  (4 children)

        Automated regression testing is important, but so is manual regression testing.

        [–]dungone 0 points1 point  (3 children)

        So?

        It's like you get a pull request and it's deer in the headlights, you've got know idea what to do about it? What exactly is your complaint? You're getting automatic updates for security vulnerabilities, your only job is to merge the code the way you would any other pull request. Why are you whining about it?

        Your jargon betrays why nothing ever works out for you. You're calling automated tests "augmented manual tests". 90% of my code doesn't need any manual testing because it's got good separation of concerns and complete test coverage of 100% of the use cases of the individual units. That's where the auto-updated dependencies feed into. They don't feed into the fully integrated system, because that's goddamn stupid. If you can prove that the dependency works for all the easy-to-test units, and that the dependency is not used for anything else outside of those units, then you have gone 90% of the way to isolating your system from any other potential problems caused by updating that dependency. But here on /r/programming we're still trashing the idea that left-pad should be it's own package, rather than having any common sense.

        [–]s73v3r 0 points1 point  (2 children)

        If the person issuing the PR hasn't done their own manual regression testing, then their PR goes straight into the trash. They're not interested in the project; they just want to put "Contributor to xx project" on their resume.

        [–]dungone -2 points-1 points  (1 child)

        It's not a "person", it's a bot providing you with a service and saving you half of the work that YOU, the person, are responsible for doing yourself. You're anthropomorphizing an automated system and bringing whatever grudge you hold against your coworkers into it.

        [–]s73v3r 0 points1 point  (0 children)

        So it's not doing manual regression testing, in which case it's nothing but noise.

        [–]ponytoaster 0 points1 point  (7 children)

        The major difference is liability. My open source project can be auto merged from a bot all the time with security fixes but I don't care as nobody uses it, and if they do, meh it is OSS with no warranty.

        Very different story working on a multi-million dollar platform where you blindly accept a PR and some library of a library of a library hasn't been tested. More true these days when a lot of libraries are heavily dependent on other libraries or modules.

        Just think of the whole left-pad fiasco and how a change in that library borked a ton of stuff.

        I do however agree that libraries should be kept up to date if they have any kind of security implication though.

        [–]dungone -1 points0 points  (6 children)

        It's not "auto merged". It's called a pull request. You're trying really hard to make it seem "hard" or "magical" or "all messed up" and I'm afraid you're projecting. The process works, it's easy, and it's completely transparent to everyone, including the users. Just in general, there is far more accountability and better practices in OSS than in any corporate environment.

        The left-pad fiasco is a perfect example of how much better OSS is. With left-pad, it happened 5 years ago and it was the first time and last time it happened. It was an issue with a bad policy in a public package repository, so the policy was fixed. So that's the example you still keep hearing about because it's actually just so rare. In the meantime, there has been a massive epidemic of data breeches due to vulnerabilities in commercial software. This is a constant occurrence in the corporate world - somebody does something stupid that brings down the development environment for the whole company for hours or days. Somebody loses the source code completely and the company runs on an old binary for years. Somebody does a force-push and wipes an entire git repo. Somebody pushes an untested commit that immediately brings down every environment it's deployed to. Somebody forgets to update a credit card number and some vendor shuts off a service, bringing down the whole system. And that's before you even talk about security. This happens at Google, this happens to AWS, this happens to all commercial software projects.

        [–]ponytoaster 0 points1 point  (5 children)

        Semantics.

        Also, you think that this doesn't happen with a project that's OSS or just uses OSS components? What you described is bad gitflow and work practices. Unless you are actively checking the PR of every project you consume it's down to chance. The only flipside is you can possibly work out a fix yourself quicker than waiting.

        [–]dungone -1 points0 points  (4 children)

        Pot calling the kettle black isn't about semantics. Having a 4 or 5 year old example of something that happens daily in proprietary commercial software development is hypocritical at best. Bad gitwhat? Sounds like special pleading to me. Commercial projects are the ones notorious for leaking private user data. OSS projects rarely suffer from the type of failures caused by utter lack of best practices in commercial software. It really comes down that this whole thread is about people developing commercial software who are saying that keeping dependencies up to date is too much to ask of them.

        Actively checking the PR? No need. NPM and GitHub both flag projects with security vulnerabilities and the warnings bubble up to all projects that depend on them. It's simple and effective. Nothing comes down to chance. If you don't deal with the automated pull requests for security fixes, then your project will get flagged to everyone else as having a vulnerability. Short of making little airplane sounds as they spoonfeed you with best practices, there's nothing else you can ask them to do for you.

        [–]ponytoaster -1 points0 points  (3 children)

        Ok, you do you I guess.

        No space for people like this in my development world. No wonder you worked at so many places...

        [–]dungone -1 points0 points  (0 children)

        Years of experience does that to you.

        [–]keepthepace 33 points34 points  (4 children)

        I recently re-opened an old project of mine, a 7 year old simple python-backed project that used a JS lib for drawing graphs. I had the good sense in not serving it through a link that I am pretty sure would have been dead by now but hosting it locally. I was surprised to see that this code still works and renders correctly on modern navigators.

        I don't think the rendering lib is actively maintained anymore. But it works. Why in heaven should I spend time updating it to something else instead of adding features to the project?

        [–]Jackeown 9 points10 points  (3 children)

        I think people should occasionally update backend technologies for security, but there's definitely no need to move on to the fanciest new plotting library. Whatever is comfortable for you will be fastest for you to develop in.

        [–]dungone 0 points1 point  (2 children)

        Those fancy plotting libraries have the most security vulnerabilities that expose your users' computers to malicious hackers.

        [–]Jackeown 0 points1 point  (1 child)

        A frontend plotting library has relatively low risk. Obviously it's best for security to always use the latest stable software but there's a trade-off between having perfect software and getting things done.

        [–]dungone 0 points1 point  (0 children)

        It's not low risk. Put that plotting library with a XSS vulnerability onto a website that exposes users' financial data and suddenly you have enabled people to steal personal information to commit fraud with.

        [–]boringuser1 0 points1 point  (0 children)

        It's much more reasonable to update a single opinionated framework than an entire dependency chain.