Never update anything

> The only way I could see this working would be if AWS charged the holdouts the cost of keeping them supported.

That actually sounds like a great idea. They could charge more for use of older versions, so that people could calculate their tradeoffs, and migrate when they decide themselves.

Of course you won't have any problems with an empty hello world. Now develop it into a medium to big real-world project and let it sit for a year or two, then try to update dependencies (because you need new functionality or to fix some vulnerabilities).

It's never easy. For some projects it took me about a week to do this (because of a breaking change in some library that's used everywhere that you are forced to update).

I just spent another two hours fighting with breakage because of a library that shall remain nameless. The author introduced yet another major breaking change in a minor release. I'm thinking of migrating to a hand-rolled solution, it probably makes sense in the long run.

Edit: just for comparison, the backend for this project is written in Java/Spring. I recently updated it from a five year old Spring version (plus a dozen dependencies from the same time frame), and it took less than an hour to fix everything. This is simply unthinkable in the JS world.

More like compound tragedy. The world's largest search engine used to run on a single computer. Now the world's smallest app has its own kubernetes cluster.

> Actually, i don't have enough time to do my day job, learn new technologies [...] > > Ergo, i cannot update. Ergo, companies cannot ship features AND handle all of the updates [...]

Your time is limited and you can't get more of it. That isn't the case for a company. There, time == money, because if their employees don't have enough time to do all the work, they can just hire more to do the rest. But because they're only interested in growth and not sustainability, most of that money goes into developing new features, not keeping up with security updates. The vast majority of large companies could very easily hire one engineer and task them exclusively with updating legacy dependencies. And the smaller ones could instead re-task half their dev team for a month each year.

> I cannot understand what idiot thought it d be fancy cutting everything into mini dependencies that update every day without you knowing made by amateurish hipsters who transitive depend on each other like their life depended on it.

I'm not sure you're thought things through in your comment, and that you are being fair or reasonable.

No one cuts "everything into mini dependendencies". You have dependencies you reuse. That's it. When one of those dependencies gets updated, say to fix a bug or a security issue, your package manager of choice handles it for you without any issue. Still, if you do not want to fix bugs or vulnerabilities in your code then you are free to pin them all and move on with your life.

At most, the JavaScript or NodeJS crowd needs to have a serious talk about standard libraries and third party lackages, such as whether using packages such as rimraf is desirable.

> and yarn/npm frontend projects that cant be even rebuilt two weeks later

You only experience that sort of problem if you're incompetent in how you manage your dependencies.

With npm you can a) pin major/minor/patch versions of specific packages, b) save your package-lock.json file which specifies exactly which dependencies you use. If you free-float any dependency then that's something you chose to do.

With JavaScript/NodeJS + npm you only shoot yourself in the foot that way if you purposely aim at your foot, remove the safety, and press the trigger really hard.

> And I m very against transpilers and linters which I try to avoid for sanity (...)

Complaining about linters because they test your sanity is a major red flag on your approach to mundane coding tasks. This, and your casual criticism on everyone else's code, leads me to suspect that you really need to do some introspection.

> I kid you not we have an entire team in charge of one small frontent management tool for a pretrade backend, they literally spend 99% of their time justifying why they wont change it, and 1% begging me to join for a week to reorder their column or put a new button...

Based on your comment and on my experience with similar projects, I suspect you're either oblivious and/or leaving out important bits of the story just to continue plowing with your humblebrag, or you're succumbing the need to be hyperbolic.

Frontend development has to deal with far more details and constraints and requirements than any backend task. Frontend is what both clients and PMs and executives look at, and the tiniest changes like resizing a button has deep implications on the business side of things. Furthermore, it's both harder to automate tests and their tests need to be more extensive.

Thus any change, no matter how small, is a uphill battle.

It's beyond me how someone who is so hard on their entire team ends up showing such weak understanding and insight of the problem domain. I know that on the internet no one knows you're a dog, but let's not get silly here.