Hacker News Reader

> Recursive dependency resolution is nice and all but isn't this going to create a massive technological debt that needs to be maintained?

Spot on. Imagine deploying an application, in 2018, that pulls down 1000 libraries, 300 of which are 6 years old versions and contain vulnerabilities (or just bugs) involving data on transit. Who is going to do all the work to backport fixes in every affected version of each library?

If things continue on the current path, I would be surprised if a typical 2018 node/NPM-based application only pulled in 1000 libraries (transitively). I just checked an application under development here:

$ ls node_modules | wc -l 517

Then I checked the current Angular 2 repository:

$ ls node_modules | wc -l 804

(Kudos to NPM 3 for finally flattening node_modules; in addition to reducing duplication and making life less miserable on Windows, it is now much more obvious how the transitive dependencies explode.)

Given the ongoing trend toward each dependency having more dependencies of its own, 1000 doesn't sound like much of a stretch. How many of those 1000+ will be up to date and lacking in critical security or functionality bugs? It sure won't be 100%.

It makes me look longingly at languages which ship with a reasonable standard library.

The frontend part of my team is using Mithril for a serious project. They seem to be enjoying it. It was chosen for the reasons you listed.

What dependencies are required? I would have thought that for basic, no-frills use, you could just load react.js and use it with no other dependencies. Are you referring to the tooling setup required for JSX? I've never used react, just curious.

    react_demo$ du -sh node_modules/
    25M     node_modules/
    react_demo$ ls node_modules/|wc -l
    79
    react_demo$ cat $(find node_modules/ -type f ) | wc -l
    287767

I think I installed react, react-dom, browserify (globally), babel. The exact details are not really important, being inexperienced with react I probably installed stuff that is not strictly necessary. However, the ease of pulling in a huge amount of dependent code makes me concerned. For a long lived stable application you will have to maintain those dependencies (at a minimum, have 3rd party maintainers who you can trust to maintain it, not break your app, not inject security issues into your app, etc).

Have had the same experience tonight - browserify etc 12 modules, 75MB, circa 12,000 files. I guess it's just the npm way but it's definitely a bit shocking for those of us who are unfamiliar with it.

That's amazing. I had no idea things were so bad.

But are those strictly react dependencies? Seems more like a demo that was doing a lot more than just using react. Eg, browserify is mentioned, but that's a totally separate project from react, completely orthogonal. So inexperience seems like a big factor here..

It's the ecosystem that's being complained about here it seems, rather than react specifically.

Javascript has an almost non-existent standard lib. Obviously Python ships with most of the kitchen sink in core. You're not grumpy, but you're misguided.

Why not create one big package that's a lib? Call it "batteries".

In fact, it already exists: Jquery.

> In fact, it already exists: Jquery.

Not these days. A lot of JS is written server-side. I'd say the likes of Underscore/Lodash are closer to being a JS "stdlib".

A lot of people like to think that software fragmentation comes without any drawback. Having many tiny libraries and/or multiple versions hurts in the long term.

I've been using Mithril for about a year for multiple single-page apps and it's great. I'd definitely recommend it.

"I don't want to sound like a old grumpy man". Hmm you failed :). On a serious note you might have noticed that there are 2 major camps of node users those who came from web frontend devs & ones adapting node at large scale enterprises/projects (paypal, walmart, netflix, joyent) so as you might guess there are solutions to address situations like this (e.g. run your own registry etc).

You sound like a grumpy old man.

> Recursive dependency resolution is nice and all but isn't this going to create a massive technological debt that needs to be maintained?

Keeping each package small and self-contained reduces the technical debt. If you depend on a monolithic library like Django, an update can be months of work with impact all over your code. If you depend on the same amount of code, but split into 100 smaller libraries, everything becomes much easier to maintain.

> Semver is not a magic bullet

It's pretty close. Having an ecosystem where everyone follows it religiously because all the tooling is built around it is really nice.

> Also, seems like a security disaster waiting to happen (I don't use CDN because I like to make sure I review code before putting it on my important websites).

It doesn't have to be. Reviewing all the code you depend on is a fool's errand IMO, but if you want to do it then NPM makes it very easy.

> Linux distributions like Debian have put in huge effort into making a packaging system that is secure and doesn't lead to dependency hell. You can argue how successful they have been but, and maybe I'm ignorant, I don't see the same effort and level of maturity in the Javascript/npm ecosystem.

The node ecosystem has been very good at avoiding dependency hell. It's well designed. They could stand to learn from Debian on the security front though.