TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

JavaScript Growing Pains: From 0 to 13,000 Dependencies

57 pointsby nikolalsvkalmost 5 years ago

15 comments

jonny383almost 5 years ago
One can see why this happens when packes like [1] and [2] not only exist, but are frequently used.<p>[1] <a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;is-even" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;is-even</a><p>[2] <a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;is-odd" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;is-odd</a><p>EDIT: my favourite part, is-even depends on is-odd.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;jonschlinkert&#x2F;is-even&#x2F;blob&#x2F;master&#x2F;index.js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jonschlinkert&#x2F;is-even&#x2F;blob&#x2F;master&#x2F;index.j...</a>
评论 #23518080 未加载
评论 #23517944 未加载
评论 #23518145 未加载
评论 #23517992 未加载
评论 #23518101 未加载
评论 #23517974 未加载
评论 #23518197 未加载
评论 #23517922 未加载
trolliedalmost 5 years ago
JavaScript really needs a proper standard library. Has any sort of central authority ever tried to drive this forward? Maybe it should fall upon the ECMA people to get this done, seeing as they’re the ones that define the ESx specs? I don’t think npm&#x2F;node is the answer either, this needs putting together from scratch without being too bloated, much like the C or C++ stdlibs.
评论 #23518291 未加载
评论 #23518230 未加载
评论 #23518244 未加载
评论 #23518219 未加载
Epskampiealmost 5 years ago
The only way for this deluge to stop is when big packages adopt a ‘as little deps as possible’ attitude. React clearly did so with only 22 deps, it’s time for others like webpack to do the same.
评论 #23517759 未加载
评论 #23517838 未加载
alkonautalmost 5 years ago
How many of 13000 dependencies are duplicates in different versions? Would it help if npm didn’t allow more than one version of a dependency? If I understand correctly, now you aren’t even warned if you have transitive dependencies to two versions of a library?
kumarvvralmost 5 years ago
I was a javascript enthusiast till a short while ago.<p>But now I strongly encourage every developer to look at .net core and asp.net for web development.<p>The entry is a slightly steep learning curve, but its well worth it. Especially if you are a lone developer, deploying to a vm in the cloud, the cost savings due to the enhanced throughput itself is substantial.<p>Creating a web api is a breeze.<p>Standard websites with a few pages and some forms can take advantage of razor pages.<p>And Blazor is an awesome alternative to React&#x2F;Angular&#x2F;Vue etc.<p>Edit : Also, the full tech stack, including developer tools are open source, as in with proper licensing. And the open source dev tools experience is also very very good. VS Code is an awesome IDE.
评论 #23518285 未加载
评论 #23519731 未加载
satya71almost 5 years ago
The author left out another option. Run away from JS ecosystem when you can. Unfortunately, it&#x27;s not possible for client-side code on the web.
评论 #23517870 未加载
hoorayimhelpingalmost 5 years ago
Something that may not be obvious: JavaScript absolutely, can not under any circumstances, break backwards compatibility. If JavaScript breaks backwards compatibility, it literally breaks the web.<p>Most of the complexity we&#x27;re seeing in projects is around that constraint applied to &#x27;modern&#x27; JavaScript - we have to translate all of our modern code into older code that older browsers can still understand. JavaScript can&#x27;t just forget the past right now - there might be a point in the future where it&#x27;s given the IE6 treatment: &quot;if you&#x27;re using a browser that can&#x27;t support a standard that is 10+ years old, tough, you need to upgrade.&quot; But we have to all move there, together, as an industry. It took a long time for us to dump IE6 in that way, it&#x27;ll take a while before we can dump ES5.<p>This is exacerbated by the fact that there is no standard library in JavaScript. Check out some of webpack&#x27;s dependencies: <a href="https:&#x2F;&#x2F;github.com&#x2F;webpack&#x2F;webpack&#x2F;blob&#x2F;master&#x2F;package.json#L14-L23" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;webpack&#x2F;webpack&#x2F;blob&#x2F;master&#x2F;package.json#...</a>. A lot of these are replicating basic functionality a standard library should provide.<p>But we can&#x27;t just blame this on environmental factors - a lot of this feels very much self inflicted. For example: node provides a file system utility for but wepack is using a different one. Maybe the fs utility can&#x27;t solve all of their problems and they need an extended one. Instead of just using the standard file system and dealing with the quirks of it, we have to write a new, slightly better one and use that instead. Locally, it might make sense for webpack to do that, but when you do it in aggregate across the industry, you end up with the death by a thousand cuts situation we find ourselves in.
评论 #23518462 未加载
bambam24almost 5 years ago
Can you imagine trying to find 22 New packages for your Java application?
awinter-pyalmost 5 years ago
&gt; there’s not much you can do except be aware of what you add to your project ... try to avoid nested dependencies when possible<p>how? cultural expectations around transitive dep size?<p>I&#x27;m <i>certainly</i> making decisions about graph complexity when designing software in house (avoid circular import deps in code, be careful about call depth in service graph)<p>But I&#x27;ve given up doing this for 3rd party deps in JS, except <i>maybe</i> at the point where `npm install` starts to bog down and I&#x27;m like &#x27;this one isn&#x27;t for me&#x27;
austinpenaalmost 5 years ago
Why is javascript (seemingly) so much more prone to dependency hell?<p>Is it just the standard library falling short?
评论 #23517899 未加载
评论 #23518247 未加载
nojvekalmost 5 years ago
One of my big reasons why I like Typescript. It doesn’t have any dependencies. Sure it’s a big package but very self contained.<p>Don’t use Babel if you don’t want a gazillion dependencies.<p>The JavaScript ecosystem is vast, with many tools and trade offs.
MoSattleralmost 5 years ago
The problem is really not as big as most commenters here make it out to be.<p>With most modern bundlers, bundle size is rarely the problem anymore. NPM audit helps detecting and fixing security vulnerabilities of dependencies. And build process breaking because of dependencies is rather a sign of having a bad CI pipeline.<p>I am not saying it is great to have many dependencies, but it&#x27;s really not THAT bad.
评论 #23518095 未加载
评论 #23518087 未加载
评论 #23518163 未加载
mrlonglongalmost 5 years ago
Just thinking about npm makes me feel really ill.
chrismorganalmost 5 years ago
I don’t believe “13,000 dependencies” is counting the right thing at all. In actual fact, I think the number is only 756 or 691, depending on how you count it.<p>If you look at the eventual package-lock.json and filter it to just lines containing “resolved”, it’s only 756 lines, because it does plenty of deduplication. I don’t have the time to waste on installing it all myself to check, but I <i>think</i> it fails to deduplicate some that could theoretically be deduplicated, because of incompatible versions: I <i>think</i> that if you have dependencies <i>a</i> → <i>x@1</i>, <i>b</i> → <i>x@2</i>, <i>c</i> → <i>x@1</i> and <i>d</i> → <i>x@2</i>, it’ll pick one of those versions of <i>x</i> (no idea how it chooses—first it encounters, perhaps?) to sit at the top-level node_modules, and any packages that need another version will install their own version, so that in this situation you might get node_modules&#x2F;x (version 2, used by b and d), node_modules&#x2F;a&#x2F;node_modules&#x2F;x (version 1) and node_modules&#x2F;c&#x2F;node_modules&#x2F;x (version 1, again). I say this based upon very vague recollections of things I read and interacted with years ago, and the structure of package-lock.json; I may be wrong in the details of it.<p>This way of having multiple copies of the same version of the package is the difference between 756 and 691—there are 65 exact duplicates. For example, you get debug-2.6.9 at the top level, and then within other dependencies, you get three copies of debug-3.2.6, and five of debug-4.1.1. That’s just one example. There are eight copies of four different versions of kind-of. After excluding these exact duplicates, there are then another 67 cases of multiple versions of the same package being installed (kind-of’s four versions is the most).<p>A few days ago I looked at a case that was double the size of all this: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23488713#23490055" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23488713#23490055</a>.<p>When you get duplicates with incompatible versions like this, it strongly implies unmaintained, or occasionally incorrectly maintained, software. If they all got their act together and simply updated to the latest version of all their dependencies, the number of packages you’d install would not exceed 624.<p>Look, it’s still a lot, and I scorn many of them as unnecessary and oft counterproductive frivolities, and there’s way too much overlap in many of them; but 13,000 is just a shock number that doesn’t represent what people expect it to represent, or match what they’re concerned about.<p>(Also this number doesn’t mean you’re taking code from over six hundred sources; some things are just split up into multiple packages because they genuinely are separate concerns; for example, there are 93 packages named @babel&#x2F;*, indicating first-party code from Babel.)
speedgoosealmost 5 years ago
The weekly JavaScript&#x2F;NPM bashing thread is there. I started to fill my bingo grid.
评论 #23517973 未加载
评论 #23518515 未加载