JS apps nowadays have so many layers that often something breaks over time or if you run it with the wrong version of node.

Frontend post react is an absolute nightmare: My experience with a fleet of semi abandoned next.js static websites is pretty terrible: just in months something stops working in my pipeline on vercel and I need to spend time to debug it. Running things locally is even worse, I just change the code, push and hope for the best.

Python is a downright nightmare: between 2vs3 and pip, egg, venv, I usually just salvage the code I need and try to make it work or convert it to something saner (eg. I did that with an opencv algorithm I found - I just transposed it to rust + the same opencv api calls). My favourite story happened literally 2 days ago. I was trying to install a dependency (keras_ocr) and I kept failing on some dependency; I tried installing that dependency manually and it worked but no success on installing keras_ocr. Eventually I updated pip and it started working.

I had huge problems running old Go software, I think I succeeded once after a lot of pain and gave up the other times.

I had fairly good results with ancient C, C++, Java and Haskell. Probably because they started before we had cool and glamorous developers on twitter selling you a course and not maintaining his 200 leftpad libraries.

I'm curious to see where Rust will sit in a few years.

Hey jokethrowaway. I'd love to get more color on your experience upgrading your Next.js sites: feel free to email [email protected].

- On local: `npm i && next dev` is guaranteed to be stable.

- On remote: your pipeline is guaranteed to be stable.

If you have an example where this is not the case, please let me know.

I could've been more clear in my original post. I'm not just thinking about "getting an app running": ruby, rbenv, and bundler has had that solved for many years, and npm, nvm (or whatever and js is stable there as well.

If you take any app built three years ago, you are going to have critical security vulns in libraries you depend on. With java think of the log4j fiasco. With Ruby there are nokogiri or rails things. With javascript there are probably at least a handful of downstream packages that have pretty big security issues. Now you have to update dependencies, and then the real fun begins.

If it a walled-off intranet app on a VPN, or a small CLI app, sure, maybe you can ignore that issue. But if its a public web or mobile app that is gonna see real use, you are going to have to head down the security audit + package update rabbit-hole.

For what I do in my day-to-day, security vulnerabilities are reported by `npm` automatically when updating packages and there are several pieces of nice tooling around identifying the versions that exhibit the vulnerability and getting around them.

I think the `npm` community is going in the right direction and learning from mistakes of the past on this topic.

I mean, bundler goes back a pretty far distance into the history of rails at this point and has been the defacto mechanism of dependency control for ruby for most of its history by now, so barring old gems being yanked you should be able to run any rails app with a lockfile if you also find the right ruby version.

Js (or specifically npm) and python were far slower to adopt this convention, to the point that I think it's fair to say that neither have fully adopted it yet.

Js at least has made almost no backwards incompatible syntax or core lib changes though, which is a point in its favor. Ruby 2 and python 3 were major breaking changes.

For JavaScript, I generally assume backwards-incompatible changes are a non-starter because of its embedding into the browser as its killer app. At this point, we really don't know what websites will break if backwards-incompatible JS changes are made.

Ironically, this has made JS a very stable language (though APIs do occasionally drop out or change drastically for security reasons).