Live data from Hacker News

Ride down into JavaScript dependency hell

blog.appsignal.com

91–100 of 149 posts

Re: Ride down into JavaScript dependency hell

#91

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

In my experience is the people who complain most audibly about npm are the same folks who think nothing of spending a few days debugging classpath issues.

Re: Ride down into JavaScript dependency hell

#92

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

Yes, exactly. I used to think isolating dependencies like npm/yarn do, where each package has its own copy of its own dependency tree (ignoring deduping), was crazy, and potential conflicts should be a forcing function to encourage you to minimize dependencies in the first place. But then I started using these systems and it's by far the least time I've ever spent worrying about deps. There are downsides to this and how it encourages dependency proliferation, and I still believe in minimizing your dependencies, but it's the least bad system I've seen.

Re: Ride down into JavaScript dependency hell

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

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 management ended up being a bit worse, again because Node lowers the barrier of entry for inexperienced programmers to publish packages on impulse, even if they don't plan to maintain them. And its just undeniable that Javascript is a heavy intro language, so the average developer quality (especially around responsible dependency management) is probably less than other languages.

But the package count stats need to just die. When we talk about dependency bloat, useful stats would be:

- What is the average/median number of (deduplicated) dependencies in a Node program vs a Rust/Python/Ruby project?

- What is the average/median number of lines of code in a Node package, minus its dependencies? How does that compare to the average/median package in Rust/Python/Ruby?

- What is the average/median number of outdated dependencies in a Node package, vs the average/median in Rust/Python/Ruby?

- What are the average/median number of different authors across a Node package's dependencies vs Rust/Python/Ruby?

- What percentage of the Node ecosystem actually gets used? Are we looking at a long tail of mostly ignored packages, or is usage fairly spread out and diverse?

Heck, even this mostly useless graph would be better if it just adjusted for the number of users for each platform. It's pretty tough get that data, but there are sources you could look at to try and guess, including StackOverflow's dev surveys[0].

The "how many packages are there" metric means nothing when it's quoted in isolation from other data. It's like claiming Windows developers are vastly more productive than Mac developers because more Windows software exists.

[0]: https://insights.stackoverflow.com/survey/2019#overview

Re: Ride down into JavaScript dependency hell

#95
post #83
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…

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 most of it is that the ecosystem culture defaults to "always grab the latest versions of everything".

And npm only got package-lock.json a few years ago, not "from day one". Prior to package-lock.json, builds were wildly unpredictable - like, expect breaking changes week to week even if you don't change anything at all in your code.

If you want an "entirely self contained" payoff, languages that produce static binaries are pretty hard to beat. Node is not that.

Re: Ride down into JavaScript dependency hell

#97
Sometimes I feel like I am becoming increasingly out-of-touch with reality with how far this NPM/JS ecosystem nonsense has been taken. Is anyone still using this crap for de novo business applications that have real-world consequences? I have no problem if you want to build fantastical, sprawling node implementations for fun and potentially personal profit, but when your decisions start to involve other professionals who are simply trying to get the features implemented so they can go home...

I feel like we need to really think about the consequences of making these kinds of technical choices, especially in 2020 given all the horror stories circulating. Someone is eventually going to have to come in after the fact and scrape all the gore off the walls and redo your webapp in .NET/Rust/Go/etc. Why not start there and be done with it? You could save so much frustration. Is it about subjective/artistic preferences? At what point should the business owner start getting involved in these technical decisions? If the business owner found out their webapp was trapped in hell because you had a personal aesthetic attraction to one language over another much more pragmatic language, how do you think they would respond?

Re: Ride down into JavaScript dependency hell

#98
post #83
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…

> A docker image for a node project should just be "install node && npm build"

That defeats the purpose of having separate dev and runtime dependencies and results in a huge docker image filled with dev-time dependencies.

Also, other package managers do this fairly well. Java has maven and uber-jars (for self contained artifacts), python has pip and venv, etc.

Re: Ride down into JavaScript dependency hell

#99
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…

Heck, in javaland the paractice now is to put the build tool in the repo, as you will only update maven once in every decade git won't complain too much about the binary, or you can just update the version in the wrapper and put the binary on the git ignore. First time you run it, it will update the build tool.

Nowadays on javaland you should only need to have JDK and git/svn/hg/(wtv version control you use). And with the JDK, you can always download the most recent that java is backwards compatible.

Re: Ride down into JavaScript dependency hell

#100
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…

Yes and now lock files exist?

Are you actually arguing over the state of JS development from 4 years ago?

Post reply on HN