If you're running years old js runtimes in a bigcorp that doesn't feel like updating for the next decade, I'll pray for you. (Because there's nothing else to do.)
Smolcorp here, we just went from 12-20 across several large projects, it was gnarly. And now, 20 is already set to sunset soon. at some point it just feels like you should give up trying, but I'm hoping 20 to >20 isn't as bad as 12 -> 20
I work with both node and Python. The difference in upgrade experiences is measured in several orders of magnitude. My most recent few projects jumped Python versions because features I wanted were introduced. I cannot remember a time I had to rewrite application code because of an upgraded Python version (well I do, it was the Python 2 to 3 migration a very long time ago).
In the meantime new node versions constantly break backwards compatibility. Upgrading packages is a mess. Runtime environments are not properly isolated, third party packages sometimes explicitly do not work with specific versions of node, etc. For a community so focused on creating tooling, it has the worst tools of any ecosystem I have seen. I would rather work with C than with node.
Really, can you give a more specific example? I have never had a node upgrade break my code, and would be fairly surprised if I were to run into that situation! I also don't quite understand your other points - runtime environments are isolated, that's the point of the node_modules folder, and it's one of the things that Node/NPM does particularly well at. Were you installing your packages globally?
See my other comment but also npm is installed globally and global packages are available so there is no isolation. Compare to Python where a virtual env is complete with a separate copy of the Python interpreter, associated tools (pip, etc.), and only local packages are available. And best of all, you can call binaries inside the virtual env from outside it as normal executables and it just works. No need to mess with $PATH or set any other env variables, just call ./venv/bin/foobar and foobar will run in the context of that venv. Recreating this on a different machine is amazingly simple if you can use one of the already available Python binaries on that system, and trivial if not (compiling Python takes a few minutes and there are lots of tools that will make that process even simpler than the two commands you need to do it). People talk about Docker being the universal environment to run things but Python development doesn’t even need that 99% of the time. And the standard library is chock full of sane, performant modules that allow you to do everything you need, from asyncio to parsing arcane binary formats. My installed packages typically number in dozens, not thousands like JS, because the standard library provides so much already.
Yeah it’s pretty much this. Something simple like scss/sass breaks a little too often but that’s the easy case. When it’s a Postgres driver it gets even more interesting.
Using only the bundled APIs of node and python, I feel like python breaks more often, like for example the useless rename from `collections` to `collections.abc`.
Oh man 12 -> 20 must have hurt. In my experience, Node really stepped up their game in most any regard after the iojs split, and these days I've had almost zero problems jumping from one major LTS release to the next.
Can't guarantee no issues, but my gut feel is you'll have a much better experience with 20 -> 24 for example.
I know it doesn't always work out, but it definitely helps to keep current, rather than performing a massive update every X years. Most of the time the changes are minimal, but they add up over several major revisions.
Of course, every now and then something like eslint will completely break every project in existence by changing the configuration format, then you have to wait for all of the plugins to be updated (if ever), then hope all your linting rules are still valid... yeah I'm still bitter about that one.
I just moved an eslint config from a project started a little over a year ago to a fresh project and migrating the config took up way more time than I expected. The old config had options that didn’t make sense in the new config, or that weren’t covered in the migration docs, etc. I think it all works now but who knows if some odd rule got missed and that’s just that from now on
Picking Javascript as the foundation of your project and being dismayed at how much work it takes to keep up is a restatement of the definition of insanity.
