Yes, that is mostly true, but it glosses over two big problems with the JS ecosystem.

The first is that longevity seems to be a dirty word. I have seen professional JS developers say, without a hint of irony, that their code only needs to last a year, maybe two, so it doesn't need to be designed for long-term maintenance or ongoing development. That same attitude exists in much of the library and tool development, which means while your code might still run in 2 or 5 or 10 years, the dependencies for your code might not have kept up. Even if they still run, they're stuck at whatever level of features and security and flexibility they had when they were abandoned, which might well have been only six months or a year after you added them to your project. Now you have a perma-brake applied to everything you do.

The other big problem with the JS ecosystem is that JS itself is a moving target. Thanks to evergreen browsers, Node, and those controlling them, standardisation and stability also seem to be dirty words now. Your code from 10 years ago, using only basic JS language features, might still run. Unfortunately, your code from 2 years ago, using whatever alpha/beta quality JS features supported promises or observers or local storage at that time, might not. And the same goes for code in dependencies you introduced 2 years ago that are already abandonware.

Multiply those two factors and you have a recipe for instability and frequent unexpected failures unlike anything I have ever seen on any other platform.