3 ms·

I don't think it was a joke, and the problem is real. Last year I had to spend significant amount of time updating a basic frontend that was "only" three years

by arp242 4y ago

I don't think it was a joke, and the problem is real. Last year I had to spend significant amount of time updating a basic frontend that was "only" three years old. "npm install" told me I had over a hundred security problems (most weren't really applicable or a big deal, but still), but updating things was hard as almost everything had incompatible changes; some had several major version bumps. Since I didn't write the original application and wasn't familiar with all the libraries used it felt like joining Game of Thrones in the middle of season 4 and figuring out what was going on. All in all, I spent about a week of full-time work. The backend was written in Go; everything could be updated to the latest version without any incompatibilities at all. People having been complaining about incompatibilities in Rust too, but Rust is a much newer language, and I think things have settled by now as well. I don't know much about C#.

zdragnar 4y ago
Sure, and in another three years you'll be saying the same thing about go because the introduction of genetics has changed everything. Java went through the same thing with the transition of java 9, introduction of lambdas, etc. Python went through 2 to 3 in the same time period. C++23 is in the works, and many parts of the ecosystem are just now getting support for 11. I'm not saying the problem doesn't exist, or that's certain parts of the ecosystem haven't experienced more churn than others. I am saying that "js churn" has been a meme joke for a long time, and has been old for almost as long.
- arp242 4y ago
  > in another three years you'll be saying the same thing about go because the introduction of genetics has changed everything I'm not so sure about that; things haven't really changed that much. A language gaining new features doesn't typically break everything, even when libraries start adopting them. But even if it does: sure, languages can have their "everything changed" watershed moments, but no such watershed happened in JS in the last few years, yet updating things is still a lot of effort, and a bit of a pain. It actually has nothing to do with the language; it's just the mindset. For whatever reason compatibility is just not high on the list of priorities in the JS ecosystem. I maintain Go packages that have been compatible for over 10 years; I make special effort to ensure they remain compatible, and even if a compatibility break is required I try to minimize it. There is nothing in JS or npm preventing the same kind of mindset. Either way, it's not a "meme joke" and it's certainly not "old" as the problems still exist today. If you (or someone else) would say "I think the advantages of moving faster are more important than remaining compatible": okay, fair enough; I can see that's a reasonable point of view, even though I personally don't agree with it. What I always find off-putting is the casual dismissal of the problems. The Python 3 transition could have been handled better and dependency management remains a bit of a mess in Python: I don't see many Python developers deny these are (or were) real problems.

by arp242 4y ago

zdragnar 4y ago

Sure, and in another three years you'll be saying the same thing about go because the introduction of genetics has changed everything. Java went through the same thing with the transition of java 9, introduction of lambdas, etc. Python went through 2 to 3 in the same time period. C++23 is in the works, and many parts of the ecosystem are just now getting support for 11. I'm not saying the problem doesn't exist, or that's certain parts of the ecosystem haven't experienced more churn than others. I am saying that "js churn" has been a meme joke for a long time, and has been old for almost as long.

arp242 4y ago
> in another three years you'll be saying the same thing about go because the introduction of genetics has changed everything I'm not so sure about that; things haven't really changed that much. A language gaining new features doesn't typically break everything, even when libraries start adopting them. But even if it does: sure, languages can have their "everything changed" watershed moments, but no such watershed happened in JS in the last few years, yet updating things is still a lot of effort, and a bit of a pain. It actually has nothing to do with the language; it's just the mindset. For whatever reason compatibility is just not high on the list of priorities in the JS ecosystem. I maintain Go packages that have been compatible for over 10 years; I make special effort to ensure they remain compatible, and even if a compatibility break is required I try to minimize it. There is nothing in JS or npm preventing the same kind of mindset. Either way, it's not a "meme joke" and it's certainly not "old" as the problems still exist today. If you (or someone else) would say "I think the advantages of moving faster are more important than remaining compatible": okay, fair enough; I can see that's a reasonable point of view, even though I personally don't agree with it. What I always find off-putting is the casual dismissal of the problems. The Python 3 transition could have been handled better and dependency management remains a bit of a mess in Python: I don't see many Python developers deny these are (or were) real problems.