Ride down into JavaScript dependency hell • Hacker News Board

Re: Ride down into JavaScript dependency hell

#121

Post by jdminhbg » Sat, Apr 11, 2020, 8:42 PM UTC

lmkg wrote: post #112

ng12 wrote: post #84

Earlier quoted context omitted.

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

The issue with NPM is that packages tend to be more granular than other languages. For example: The npm package "is-even" depends on the "is-odd" package. (In case it's not clear, this is a real package, not a made-up example.) In most other languages, these would be bundled together into an Integer Utilties package, if they're not already part of the standard library. In NPM, they are separate packages. I believe th…

> In most other languages, these would be bundled together into an Integer Utilties package, if they're not already part of the standard library.

This is the root of all the many issues. There is no standard library. So things that are trivial to write but also dumb to rewrite every time you need them (left-pad a great example) turn into tiny dependencies.

Re: Ride down into JavaScript dependency hell

#122

Post by seumars » Sat, Apr 11, 2020, 8:43 PM UTC

This wouldn't be much of a problem if developers weren't as reliant on frameworks as JS developers are — who for some reason love to blame others for "reinventing the wheel". What do people even use lodash for? Do you really need a whole library because you can't write a function to sort an array? This all reminds me of the npm left-pad scandal. To me the problem was not that a single package broke thousands of projects, but that thousands of developers depended on a package for such a simple feature.

Re: Ride down into JavaScript dependency hell

#123

Post by jacobolus » Sat, Apr 11, 2020, 8:57 PM UTC

lmkg wrote: post #112

ng12 wrote: post #84

Earlier quoted context omitted.

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

The issue with NPM is that packages tend to be more granular than other languages. For example: The npm package "is-even" depends on the "is-odd" package. (In case it's not clear, this is a real package, not a made-up example.) In most other languages, these would be bundled together into an Integer Utilties package, if they're not already part of the standard library. In NPM, they are separate packages. I believe th…

> For example: The npm package "is-even" depends on the "is-odd" package. (In case it's not clear, this is a real package, not a made-up example.) In most other languages, these would be bundled together into an Integer Utilties package, if they're not already part of the standard library. In NPM, they are separate packages.

People should not be using these functions at all, in any language, in a standard library or otherwise. To convert the even/oddness of an integer to a boolean in Javascript you can use !!(n % 2), which returns true for odd inputs, and false for even inputs. If you want to be extra explicit you can temporarily store the result of that expression in a meaningfully named variable. If it will just be used in a conditional, then the !! can be skipped.

Depending on a third-party package for this kind of thing is insanity. But the blame lies with programmers who use this package, not with the programming language.

Re: Ride down into JavaScript dependency hell

#124

Post by leetrout » Sat, Apr 11, 2020, 8:58 PM UTC

erik_seaberg wrote: post #116

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.

Copying code is pinning a dependency, committing to never update it, and hiding the evidence.

Perhaps.

Re: Ride down into JavaScript dependency hell

#125

Post by rootlocus » Sat, Apr 11, 2020, 9:07 PM UTC

jacobolus wrote: post #123

lmkg wrote: post #112

Earlier quoted context omitted.

The issue with NPM is that packages tend to be more granular than other languages. For example: The npm package "is-even" depends on the "is-odd" package. (In case it's not clear, this is a real package, not a made-up example.) In most other languages, these would be bundled together into an Integer Utilties package, if they're not already part of the standard library. In NPM, they are separate packages. I believe th…

> For example: The npm package "is-even" depends on the "is-odd" package. (In case it's not clear, this is a real package, not a made-up example.) In most other languages, these would be bundled together into an Integer Utilties package, if they're not already part of the standard library. In NPM, they are separate packages. People should not be using these functions at all, in any language, in a standard library or…

If the standard library includes a variant for these or any other functions, it's probably idiomatic to use them. They handle edge cases, are better optimized and they're explicit.

Re: Ride down into JavaScript dependency hell

#126

Post by stickfigure » Sat, Apr 11, 2020, 9:10 PM UTC

aaomidi wrote: post #100

stickfigure wrote: post #95

Earlier quoted context omitted.

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?

I have pointed out that, contrary to the parent, Node is not special, and certainly wasn't "from day one" as claimed.

Re: Ride down into JavaScript dependency hell

#127

Post by koonsolo » Sat, Apr 11, 2020, 9:12 PM UTC

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…

Yesterday I had to use the web fullscreen API. Didn't work on an iPad, so I installed npm package screenfull that handles browser incompatibilities. Works like a charm.

These kind of things are specific for JavaScript because of the mentioned incompatibilities, and of course increase nr packages used. But I'm very happy they exist.

Re: Ride down into JavaScript dependency hell

#128

Post by lioeters » Sat, Apr 11, 2020, 9:32 PM UTC

erik_seaberg wrote: post #116

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.

Copying code is pinning a dependency, committing to never update it, and hiding the evidence.

That's not always true.

Many a time I've forked a dependency for one reason or another, and kept it up to date with upstream. Sure, it's a few more steps to update, but allows for deep customizations without waiting for original authors to support it (if ever).

Another reason to fork/copy code, is that its development has ceased long ago. In that case, it totally makes sense to carry on the work, in-house at first.

Regarding the article, sometimes copying code keeps the entire codebase easier to understand and manage without having an external dependency.

Re: Ride down into JavaScript dependency hell

#129

Post by SahAssar » Sat, Apr 11, 2020, 9:49 PM UTC

dep_b wrote: post #36

dwheeler wrote: post #13

Part of the issue is that JavaScript packages are often far far smaller than packages in other ecosystems. "small packages are extremely common in the JavaScript npm package system. For example, in npm, 47% of the packages have 0 or 1 functions, and the average npm package has 112 physical lines of code. In contrast, the average Python module in the PyPI repository has 2,232 physical lines of code." Source: "Vulnerab…

iOS dependencies in Cocoapods are including less than 1 other packages on average (1). The most I see are Alamofire (a networking package people keep using for reasons that I do not fully understand) and Starscream (a Websocket implementation, that's pretty hard to write from scratch to be honest). Having unnecessary dependencies is pretty much frowned upon. One of the reasons is that the iOS SDK is really complete b…

What makes the js Date implementation unusable in your view? IMO it works pretty okay for most needs.

Re: Ride down into JavaScript dependency hell

#130

Post by erik_seaberg » Sat, Apr 11, 2020, 10:05 PM UTC

lioeters wrote: post #128

erik_seaberg wrote: post #116

Earlier quoted context omitted.

Copying code is pinning a dependency, committing to never update it, and hiding the evidence.

That's not always true. Many a time I've forked a dependency for one reason or another, and kept it up to date with upstream. Sure, it's a few more steps to update, but allows for deep customizations without waiting for original authors to support it (if ever). Another reason to fork/copy code, is that its development has ceased long ago. In that case, it totally makes sense to carry on the work, in-house at first. R…

I guess that's not impossible, but it seems to reinvent git submodules without the tool support I'd want, and I think explicitly depending on our fork of their library would be clearer and safer.