undefined | Better HN

0 pointszimbatm4y ago0 comments

That's right, it makes the problem worse.

The first time I noticed that trend was on macOS, where applications bundle most of their libraries, and binaries compiled for multiple architectures.

Then we had Electron apps that ship with their own full copy of a browser and dependent libraries.

When NPM was designed, they observed that resolving colliding versions of the same dependency was sometimes difficult. Their answer was to remove that restriction and allow multiple versions of the same library in a project. Nowadays, it's not uncommon to have 1000+ dependencies in a simple hello world npm project.

Our industry is moving away from that feedback force that was forcing developers to agree on interfaces and release stable APIs.

0 comments

mschuster914y ago

> Our industry is moving away from that feedback force that was forcing developers to agree on interfaces and release stable APIs.

And parts of the industry are beginning to move back and favor stability, as a result of

- numerous NPM packages being taken over by coin miners and other malware - at the scale of some of them, even a ten minute takeover window were millions of installs, and source chain audits are almost impossible

- framework churn being an actual liability for large enterprises - many were burned when AngularJS fell out of love and now they were stuck with a tech stack widely considered "out of date". Most new projects these days seem to be ReactJS where Facebook's heavy involvement promises at least some long term support

- developer / tooling churn - same as above, the constant amount of training to keep up with breaking changes may be tolerable at startup, money-burn phase, but once your company achieves a certain size it becomes untenable

j / k navigate · click thread line to collapse