3 ms·

While the author isn't wrong, is it just me or does this article come off as the author just whining that they used a bunch of libraries that they didn't resear

While the author isn't wrong, is it just me or does this article come off as the author just whining that they used a bunch of libraries that they didn't research well enough first and they went out of support? This is the price you pay for the convenience of not having to write all the stuff. Yeah updates suck and it sucks people don't maintain their libraries better or write them better to begin with but people have lives and may be doing this stuff on their own isn't sustainable beyond a point. The solution could be "less people make libraries" or it could be "more people make libraries and more people help maintain them" or it could be that people who make apps stop using libraries and write the code themselves. You can't force people to maintain every piece of code they put online just in case someone uses them in one of their apps then a year later wants to update their app. What if the end user wanted a different specific version? This stuff annoys me as much as anybody but whining and posting it to hackernews is just self-flagellation.

_cenw 4y ago
It's a problem you can't really evade if you're on the modern JS stack train. A lot of that has to do with frameworks running into the same issue. Some part of the build stack retires an old version unannounced, and now you have an entire cascade of rushed out updates.
- positron6000 4y ago
  this is the price of development convenience. if you don't like modern web dev then... don't do it? plain html and css still work just fine. jquery works just fine.
  - brvier 4y ago
    Right, but, you don't always works alone, or you need to maintain choices of other dev. Really, in js echo system there are always a huge cascading update when you update one component.
Gigachad 4y ago
Pretty much. Just stop adding shit to your package list and you won't have this problem. If some major framework like React has this happen to one of their dependencies, it's at least not your problem as they will fix it for you. >Oh no, this free stuff I got wasn't good enough
nijave 4y ago
It seems there's something about the JS system that either encourages very granular/tiny libraries or makes it really easy. There's other ecosystems like Java+Springboot where you can go 2-3 years only doing minor/patch upgrades without too many changes. React is on version 18, released in 2011. Springboot is on version 2, released in 2014.
- MonkeyClub 4y ago
  Spring Boot is currently on 3.0.5, but your point stands - the changes are well thought out and the version numbers don't aim at infinity.
nikau 4y ago
> convenience of not having to write all the stuff Its the difference of not paying for the stuff. In the past you would pay a vendor and they would give you libraries and provide bug fixes and vulnerability patches.
- mike_hearn 4y ago
  And stable APIs, and large integrated product suites that solved the whole problem, and that vendor was incentivized to stick around and maintain the product even if it wasn't cool anymore. Unfortunately the way dev compensation works (i.e. mostly salaried with big jumps possible from job hopping), we're all very incentivized to go with free stuff today even if it actually turns into a major source of tech debt tomorrow. After all, if you're paid by the hour does it really matter if you spend days or weeks fighting with abandoned dependencies? It matters to the company but to the individual it can even be a benefit, because you get experience with things that look good on the CV. That in turn damages the market for developer tools, creating a self-fulfilling prophecy where not many people try to compete against free, so people conclude it's just the natural state of things and can't be any better. I see this problem with my own product: our customers mostly come to us in a sort of shell-shocked state where they've lost a lot of time and hair trying to make the available open source tooling work for them, and decide to buy ours as a sort of last resort. Then they get it all working, we help them fix any issues, they have a good experience in the end and are happy. Unfortunately people have to go through that bad experience first because everyone's initial instinct is always to go with the free stuff, and indeed they probably won't even find out about the alternatives because there's a culture in which open source projects only want to advertise or integrate with other open source projects. So the author asks, how did we get here? That's how.

_cenw 4y ago

It's a problem you can't really evade if you're on the modern JS stack train. A lot of that has to do with frameworks running into the same issue. Some part of the build stack retires an old version unannounced, and now you have an entire cascade of rushed out updates.

positron6000 4y ago
this is the price of development convenience. if you don't like modern web dev then... don't do it? plain html and css still work just fine. jquery works just fine.
- brvier 4y ago
  Right, but, you don't always works alone, or you need to maintain choices of other dev. Really, in js echo system there are always a huge cascading update when you update one component.

Gigachad 4y ago

Pretty much. Just stop adding shit to your package list and you won't have this problem. If some major framework like React has this happen to one of their dependencies, it's at least not your problem as they will fix it for you. >Oh no, this free stuff I got wasn't good enough

nijave 4y ago

It seems there's something about the JS system that either encourages very granular/tiny libraries or makes it really easy. There's other ecosystems like Java+Springboot where you can go 2-3 years only doing minor/patch upgrades without too many changes. React is on version 18, released in 2011. Springboot is on version 2, released in 2014.

MonkeyClub 4y ago
Spring Boot is currently on 3.0.5, but your point stands - the changes are well thought out and the version numbers don't aim at infinity.

nikau 4y ago

> convenience of not having to write all the stuff Its the difference of not paying for the stuff. In the past you would pay a vendor and they would give you libraries and provide bug fixes and vulnerability patches.

mike_hearn 4y ago
And stable APIs, and large integrated product suites that solved the whole problem, and that vendor was incentivized to stick around and maintain the product even if it wasn't cool anymore. Unfortunately the way dev compensation works (i.e. mostly salaried with big jumps possible from job hopping), we're all very incentivized to go with free stuff today even if it actually turns into a major source of tech debt tomorrow. After all, if you're paid by the hour does it really matter if you spend days or weeks fighting with abandoned dependencies? It matters to the company but to the individual it can even be a benefit, because you get experience with things that look good on the CV. That in turn damages the market for developer tools, creating a self-fulfilling prophecy where not many people try to compete against free, so people conclude it's just the natural state of things and can't be any better. I see this problem with my own product: our customers mostly come to us in a sort of shell-shocked state where they've lost a lot of time and hair trying to make the available open source tooling work for them, and decide to buy ours as a sort of last resort. Then they get it all working, we help them fix any issues, they have a good experience in the end and are happy. Unfortunately people have to go through that bad experience first because everyone's initial instinct is always to go with the free stuff, and indeed they probably won't even find out about the alternatives because there's a culture in which open source projects only want to advertise or integrate with other open source projects. So the author asks, how did we get here? That's how.