TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Why do JavaScript developers favour many, tiny dependencies?

3 点作者 confusedjs超过 9 年前
The more I delve in to the world of Javascript the more I come across projects such as:<p>* is-root: https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;is-root<p>* is-even https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;is-even<p>Often these are whole npm modules that comprise of a single line of code.<p>I&#x27;ve never seen anything quite like it when working with Java and Python.<p>Can anyone explain why? It seems to me adding a dependency I have to suck across the network, that may introduce breaking changes (or just disappear) is something that shouldn&#x27;t be taken lightly. Doing it for a single line of code (that realistically won&#x27;t need to change anyway) is borderline insane.<p>Am I being too paranoid or am I missing something?

3 条评论

davismwfl超过 9 年前
You aren&#x27;t being paranoid IMO, but there are reasons it is done to some level.<p>Personally, as for depending on 3rd party npm modules that only implement a few lines of Javascript, I generally avoid doing it as it feels wrong. I also wouldn&#x27;t say Javascript developers favor tiny dependencies, they are just trying to generally avoid rewriting the same line of code across multiple places since that can obviously create a lot of headaches. While there are ways to handle includes, modules etc, across projects it can get messy fast and cause lots of stability issues, but using small versioned packages generally resolves those issues, at least in my personal experience.<p>My own basic thoughts:<p>1. if you only need that code in one project, just create a small module and include it, done.<p>2. if you want to share that code amongst multiple projects utilize npm private packages, or create a local npm repository&#x2F;cache.<p>I generally opt to use npm private packages as it allows for easy reuse internally across multiple projects without having to copy or reimplement code. Plus you can take advantage of versioning them which makes life a lot more flexible and robust.<p>Also, don&#x27;t forget there are license terms that can affect which packages you use too, so that has to come into play as well when you are selecting them.
lollipop25超过 9 年前
Seriously? isEven? That can be done using `!(n % 2)`.<p>You&#x27;re generalizing, and yes, you&#x27;re being too paranoid. Not all of them actually agree on (really very small) modules. <a href="https:&#x2F;&#x2F;medium.com&#x2F;@Rich_Harris&#x2F;small-modules-it-s-not-quite-that-simple-3ca532d65de4" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@Rich_Harris&#x2F;small-modules-it-s-not-quite...</a><p>It all boils down to balance and common-sense.
评论 #11158952 未加载
davelnewton超过 9 年前
Small and focused is good. Keeps from having to import a huge library (e.g., math.js) for simple functions when you don&#x27;t need what the rest of the library offers. Small surface.<p>Would <i>I</i> use is-even? No, I&#x27;d keep it in a local utility that bundles up other things my specific app needs, or package groups of small util libs into an app-specific uber-module.