3 ms·

Isn’t most Javascript rendered useless by the time it is ready to be upgraded because all of its dependencies have moved on to not so greener pastures? On a se

Isn’t most Javascript rendered useless by the time it is ready to be upgraded because all of its dependencies have moved on to not so greener pastures? On a serious note. Keeping up with changes in the Javascript community seems like a full time job. I don’t know how they get any work done.

zdragnar 3y ago
This joke was already getting old 6 years ago. The major frameworks of today were already well established then, and the last really big update to the language in 2015 had already been in fairly wide spread use via transpilers (traceur and later 6to5, which became babel). Honestly, in the last 13 years, many mainstream languages have gone through similar churn. JavaScript has gone through more than most, to be sure, but nobody complains about Rust or C# nearly so much.
- beezlewax 3y ago
  JS is dependencies all the way down. Upgrading things can be a nightmare
  - bilalq 3y ago
    And yet, I find myself struggling way more with Objective-C/Swift and Java/Kotlin deps than I do with JS ones. Dependency upgrades can be problematic, sure, but JS is no worse than any other language. I never had to change compiler flags or mutate internals of a library in npm the way I need to do with cocoapods.
- simplotek 3y ago
  > Honestly, in the last 13 years, many mainstream languages have gone through similar churn. JavaScript has gone through more than most, to be sure, but nobody complains about Rust or C# nearly so much. Rust appeared 7 years ago. Rust did not went through any churn. Arguably, the first iteration hasn't even ended yet.
  - teg4n_ 3y ago
    Of course it has, that’s what editions are. If you don’t consider editions different then the first version of JavaScript hasn’t ended either.
    - simplotek 3y ago
      > Of course it has, that’s what editions are. They really aren't. Editions are just a mechanism to allow Rust developers to push backwards-incompatible changes as opt-in features. I repeat, Rust hasn't even went through its first iteration, and it shows a fundamental lack of understanding and insight to argue otherwise.
      - JeremyBanks 3y ago
        [dead]
- arp242 3y 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 3y 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 3y 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.

zdragnar 3y ago

This joke was already getting old 6 years ago. The major frameworks of today were already well established then, and the last really big update to the language in 2015 had already been in fairly wide spread use via transpilers (traceur and later 6to5, which became babel). Honestly, in the last 13 years, many mainstream languages have gone through similar churn. JavaScript has gone through more than most, to be sure, but nobody complains about Rust or C# nearly so much.

beezlewax 3y ago
JS is dependencies all the way down. Upgrading things can be a nightmare
- bilalq 3y ago
  And yet, I find myself struggling way more with Objective-C/Swift and Java/Kotlin deps than I do with JS ones. Dependency upgrades can be problematic, sure, but JS is no worse than any other language. I never had to change compiler flags or mutate internals of a library in npm the way I need to do with cocoapods.
simplotek 3y ago
> Honestly, in the last 13 years, many mainstream languages have gone through similar churn. JavaScript has gone through more than most, to be sure, but nobody complains about Rust or C# nearly so much. Rust appeared 7 years ago. Rust did not went through any churn. Arguably, the first iteration hasn't even ended yet.
- teg4n_ 3y ago
  Of course it has, that’s what editions are. If you don’t consider editions different then the first version of JavaScript hasn’t ended either.
  - simplotek 3y ago
    > Of course it has, that’s what editions are. They really aren't. Editions are just a mechanism to allow Rust developers to push backwards-incompatible changes as opt-in features. I repeat, Rust hasn't even went through its first iteration, and it shows a fundamental lack of understanding and insight to argue otherwise.
    - JeremyBanks 3y ago
      [dead]
arp242 3y 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 3y 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 3y 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.