Hacker News Reader

Comment by lbriner | Hacker News Reader

Definitely some issues raised in the article and particularly the idea that even if you need a little bit of something, you inherit the entire library with dependencies you don't need!

However it is a little short on solutions. The truth is that I don't want to write my own PayPal API when there is one that PayPal produce and are likely to keep more up-to-date than me. Writing my own means that I only rely on my team but it is a big overhead for any reasonable size company that use dependencies from possibly 20+ major libraries and the hundreds of lower-level dependencies.

What would be cool would be a webpack style dependency manager that can remove things you don't use and then only show you updates for the bits you do.

View on HN

It seems like "the hundreds of lower-level dependencies" is a problem that is unique to JavaScript due to its lack of a standard library.

JavaScript has a huge ecosystem, and as a result produces many new, interesting ideas, but its also the source of a lot of churn.

I remember working on large-ish (+300k LoC) .Net applications that were essentially dependent on just the .Net Framework itself.

For those looking to prioritize stability, the "solution" would probably be to avoid Node.js based applications altogether.

Use something like JavaScript/Node.js where it makes sense, in the front-end, and for developing thin API layers to support your front-ends. For heavy lifting (data and complex business logic) look towards languages/tools that prioritize stability.

avoid Node.js based applications altogether.

I ran into this recently. Firefox has a "packager" for putting together add-ons. It uses "node.js". All it really does is apply "zip" to some files. I tried to install the "packager" on Ubuntu 18.04 LTS. It had several hundred dependencies, and wouldn't run because of some version dependency in node.js for something totally irrelevant to the task at hand. Mozilla support suggested upgrading the operating system on the development machine.

I wrote a one-line shell script which zipped up the proper file types into one file to package the add-on.

The overreliance on NodeJS in "modern" Enterprise(TM) JS development is pretty weird in general, even for folks who have an affinity for having all their tools written in JS. A bunch of the NodeJS tooling could just target the browser's native JS runtime instead, which is already installed. E.g. to build the project, you clone it, double click the project's Build.app.htm file, and then drag and drop the project source tree there. I've actually already prototyped this sort of thing. This is how I plan on doing anything when working in JS going forward, whenever possible. That it's incompatible with the vast majority of the NodeJS/NPM ecosystem is a bonus.

I use the `npm-check` [0] to help me with that problem. Might not check all of your boxes, but it certainly helps me manage dependencies in my JS projects!

[0]: https://github.com/dylang/npm-check

Reply on news.ycombinator.com