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

101–110 of 149 posts

Re: Ride down into JavaScript dependency hell

#101

Post by aaomidi »

danShumway wrote: post #93
rootlocus wrote: post #81

Earlier quoted context omitted.

> - 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...

These comparisons are so bad. NPM is hands-down the most popular packaging ecosystem online. So of course it has more packages than other ecosystems, more developers use it. It's not a good comparison. I would not be surprised to find that JS bloat tends to be more severe than other languages, because Javascript makes it a lot easier to import and publish packages. I would also not be surprised if Node package manage…

Also keep in mind it's far easier to publish on npm and that's a good thing.

It literally takes days to setup shit to get published on maven central and even then you can't set and forget. It's a pain in the ass.

Re: Ride down into JavaScript dependency hell

#102

Post by takinola »

So what exactly is the problem? I see a lot of talk about dependency hell and node_modules bloat but I don't really hear much about what the actual downside is.

Is it performance (I haven't experienced it)? Is it taking up disk space (I have terabytes to spare)? Does it add complexity (I would argue it reduces complexity)?

What exactly is the problem?

Re: Ride down into JavaScript dependency hell

#103

Post by oefrha »

matheusmoreira wrote: post #74
oefrha wrote: post #73

Earlier quoted context omitted.

Point to me one package in Debian that depends on thousands more. Oh and I was a maintainer for a major package manager back in the day for crying out loud (was responsible for overseeing the general health of the project as well as directly responsible for maybe a couple dozen individual packages). Never seen this kind of madness.

I don't know about Debian but Arch Linux has huge package groups and metapackages. https://www.archlinux.org/groups/x86_64/kde-applications/ https://www.archlinux.org/groups/x86_64/pro-audio/ The Arch Wiki recommends the use of these huge packages. I don't see any reason why it wouldn't scale to a thousand packages or more.

I'm talking about one actual package that largely runs in a single process (or at least a single process group) with thousands of deps, not some sort of loosely related by category or by using the same framework (hell, we're talking about the framework itself here) package group where failure of one no name package doesn't affect anything else.

Re: Ride down into JavaScript dependency hell

#104

Post by tasogare »

pizzapim wrote: post #4

So what does NPM do differently than plugin managers from other languages? I can't name one where the dependency hell is this big.

Other languages have for most part a good standard library. In C# for instance you can make a small/medium project with only a few third party libraries because the base class libraries (BCL) contains lot of data structures and classes used for common use case (encryption, unicode, file operations, etc.)

Re: Ride down into JavaScript dependency hell

#105

Post by tpetry »

matheusmoreira wrote: post #55
BiteCode_dev wrote: post #46

Earlier quoted context omitted.

Yes and no. Because of the small stdlib, you need dependancies, sure. But why this idea that each dependency must be very small, forcing you to install a hundreds childs, which, themselves, will install a hundred until the pyramid of files start to turn node_modules into a stress test?

The problem is not small packages or huge dependency trees. It's the fact widely used packages have to be installed at all. This is compounded by the package manager which allows packages to have independent copies of their dependencies. We should have a de facto standard library that gets distributed along with the language's reference implementation. Widely-used packages that have a stable and well-designed interfa…

The problem is not small packages. The problem is there are many of these small libraries trying to solve the same problem (extending the small standard library more). And when there are no clear winners your dependency tree will be full of packages trying to do the same.

Re: Ride down into JavaScript dependency hell

#106

Post by johannes1234321 »

ng12 wrote: post #83
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 buil…

Unless any library you use depends on a native module, then you are in for surprises.

Re: Ride down into JavaScript dependency hell

#107

Post by jessaustin »

Waterluvian wrote: post #90
williamdclt wrote: post #58

Earlier quoted context omitted.

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.

This is more of that "wet streets cause rain" logic we hear about...

Re: Ride down into JavaScript dependency hell

#108

Post by ng12 »

stickfigure wrote: post #95
ng12 wrote: post #83

Earlier quoted context omitted.

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 buil…

I'm totally baffled by this statement. Find me a mainstream language that's more complicated than this? "Checkout and build" works pretty much everywhere? I mean, you need the right version of mvn or pip or whatnot... just like you need the right version of npm. If anything, node/npm deserves special mention for NOT having reliable repeatable builds. Part of this is that a lot of packages rely on native code. But mos…

To put it simply to build a modern Java project you need the jdk + bazel + docker + maven + runtime classpath for a sub-set of npm's features (as far as I know you still can't include two versions of the same maven dependency).

For a Node project you just need node. npm is part of node, and yarn is optional. The repeatable builds was a real issue but that's been solved years ago.

Re: Ride down into JavaScript dependency hell

#109

Post by jessaustin »

zacksinclair wrote: post #94

I can't help but find it ironic that in middle of this oft-repeated JS bitch fest the author's own company is promoting their NPM package.

You have to market differently to different people. TFA is intended for devs who are forced to use javascript even though they prefer python 2. They would write a different article for skilled js developers.
Post reply on HN