Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ride down into JavaScript dependency hell

blog.appsignal.com

Post reply on HN
Print view View original

81–90 of 149 posts

Re: Ride down into JavaScript dependency hell

#81

Post by rootlocus »

tmcw wrote: post #76

How to write a silly post about JavaScript dependencies: - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems. - Talk about devDependencies and dependencies without considering how they might be entirely different, say… one kind gets bundled, the other doesn't. - Always use npm, so you can highlight duplicates. Don't use yarn. - Adopt a narrow definition of 'depend…

> - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems.

The post contains a graph with the package counts for other languages [1]

1 https://d33wubrfki0l68.cloudfront.net/7481900a584f733e7e9db7...

Re: Ride down into JavaScript dependency hell

#82

Post by jessaustin »

seemslegit wrote: post #79
tmcw wrote: post #76

How to write a silly post about JavaScript dependencies: - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems. - Talk about devDependencies and dependencies without considering how they might be entirely different, say… one kind gets bundled, the other doesn't. - Always use npm, so you can highlight duplicates. Don't use yarn. - Adopt a narrow definition of 'depend…

How to downplay the severity of the problem: Ignore the ridiculously small functionality scope that acceptably qualifies for a js package in a way that does not exist in any other ecosystem and ads a big multiplier in front of all the other risks involved.

If these claims were true, we would have seen some examples by now. Instead, we get some tired invocations of "leftpad!" along with some more tired FUD. Who has been hacked because they used javascript instead of some other "more mature" language?

Re: Ride down into JavaScript dependency hell

#83

Post by ng12 »

tmcw wrote: post #76

How to write a silly post about JavaScript dependencies: - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems. - Talk about devDependencies and dependencies without considering how they might be entirely different, say… one kind gets bundled, the other doesn't. - Always use npm, so you can highlight duplicates. Don't use yarn. - Adopt a narrow definition of 'depend…

They also strategically avoid mentioning the payoff which is that your project is entirely self-contained. `node_modules` is at once your complete development kit, build tool, compiler, and collection of runtime dependencies.

Once you check out a node project with a package.json you can reasonably assume you can install it and run it anywhere. A docker image for a node project should just be "install node && npm build". You're side-stepping the entire dev ops nightmare. Find me another language with JavaScript's popularity and that level of simplicity. I'd go as far to argue that this is what happens to any massively popular language that has a functional package manager from day one.

Re: Ride down into JavaScript dependency hell

#84

Post by ng12 »

rootlocus wrote: post #81
tmcw wrote: post #76

How to write a silly post about JavaScript dependencies: - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems. - Talk about devDependencies and dependencies without considering how they might be entirely different, say… one kind gets bundled, the other doesn't. - Always use npm, so you can highlight duplicates. Don't use yarn. - Adopt a narrow definition of 'depend…

> - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems. The post contains a graph with the package counts for other languages [1] 1 https://d33wubrfki0l68.cloudfront.net/7481900a584f733e7e9db7...

Is node's biggest crime is that it's easy to publish packages? Is this an argument for intentionally complicating package systems?

Re: Ride down into JavaScript dependency hell

#86

Post by seemslegit »

jessaustin wrote: post #82
seemslegit wrote: post #79

Earlier quoted context omitted.

How to downplay the severity of the problem: Ignore the ridiculously small functionality scope that acceptably qualifies for a js package in a way that does not exist in any other ecosystem and ads a big multiplier in front of all the other risks involved.

If these claims were true, we would have seen some examples by now. Instead, we get some tired invocations of "leftpad!" along with some more tired FUD. Who has been hacked because they used javascript instead of some other "more mature" language?

There is more to dependency risk than 'getting hacked' - correctness, maintainability, IP due diligence all play a role.

Re: Ride down into JavaScript dependency hell

#87

Post by montroser »

It's not really hell though, is it? Hell is infinite pain and agony. This is more like an occasional bother.

Yes, we get comically large numbers when we look through node_modules. But, real "dependency hell" is when you have situations that take unbounded manual effort to resolve.

How often do we end up with impossible circular dependencies? Or conflicting versions clobbering each other? Or non-deterministic builds introducing random behavior?

That all is commonplace even today with other platforms like python, and rarely an issue with node. I'd much rather occasionally sneer at the size of node_modules than any of that actual hell.

Re: Ride down into JavaScript dependency hell

#88

Post by diggan »

dgellow wrote: post #60
williamdclt wrote: post #54

Earlier quoted context omitted.

I don't agree with you on this. The JS (or NPM) way makes it a pain to audit a project due to thousands of dependencies, but it's far easier to "have everything working". `npm i && npm start` is as good as it gets in terms of "getting started" friction (with version locking): python is worse, ruby is worse, PHP is worse, Java is worse. React-Native has more moving pieces indeed, but it's not really JS's (or NPM's) fa…

I've done 3 years of Golang as my main language, my experience is: - go build ./... builds everything from the current project - go test ./... tests everything from the current project - go install ./... installs everything from the current project That's one of the best thing ever. I can go to any project, I know how to build, test, install, and can directly be productive. On the other hand, I started learning C++ o…

Golang does a lot better than other languages (but probably the language that allowed me to use the most unmaintained/oldest projects is Clojure, I can't remember/find out when the oldest breaking change to the language was), but the situation in Golang was piss poor not too long ago, when Golang libraries were all fetched from GitHub/Git sources without any way of specifying specific versions, you basically lived on the edge all the time. There was third party tools to work around this (and the ever present vendoring technique) but seems weird they didn't realize this until gomod started being a thought.

Re: Ride down into JavaScript dependency hell

#89

Post by ng12 »

smitty1e wrote: post #14
leetrout wrote: post #10

Earlier quoted context omitted.

My personal take having “grown up” with all of this - JS is one of the worst ecosystems for relying on external packages for everything. It’s more the culture than the tooling. One of the things I love about Go is generally people are a little more forgiving to copying something around a couple times instead of making a lib for everything.

Inviting the question of why the culture hasn't sprouted a "package rationalizer" to produce a curated, tested, noise-filtered distribution of useful functionality. Come to think of it, something that does for packages what jQuery did to bring (some) sanity to browser incompatibilities.

Because we can't even agree on whether React or Vue or Angular is best.

In fact this is the root of the issue. It's important to realize that `node_modules` for any project in Popular Framework X will be almost identical. Most of the packages are related to compiling, bundling, and the development environment and a small minority are actual client-side dependencies. Even the frameworks themselves are pretty light -- React has a grand total of 2 dependencies. It's packaging the entire toolchain that causes most of the bloat.

Re: Ride down into JavaScript dependency hell

#90

Post by Waterluvian »

williamdclt wrote: post #58
brobdingnagians wrote: post #33

Earlier quoted context omitted.

These types of issues are the biggest reason why I avoid javascript/npm projects. I came back to a project after a few months and it was broken, had to rewrite some parts and upgrade other parts just to get it to run again.

I'm sorry but for all the flaws of the NPM ecosystem, version locking is not one (both `npm` and `yarn` do much much better than anything in Python). There's no reason a correctly set-up project would magically break with time. I don't love NPM anymore than the next guy, but my blame will go to the dev in this case.

Python dependency management is a disaster. But I find myself using far fewer dependencies with Python projects so I suffer the pain less.
Post reply on HN