5 ms·

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 JavaScri

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: "Vulnerabilities in the Core: Preliminary Report and Census II of Open Source Software", The Linux Foundation & The Laboratory for Innovation Science at Harvard, by Frank Nagle, Jessica Wilkerson, James Dana, Jennifer L. Hoffman. https://www.coreinfrastructure.org/programs/census-program-ii/ https://www.coreinfrastructure.org/programs/census-program-i... (This is a contrast of citations from other works; you can see the specific citations in the report, but I'm trying to do this from a phone. In any case, the issue is the massive difference between JavaScript and everything else, and I think this quotation shows it nicely.)

dep_b 7y ago
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 by itself while Javascript doesn't even ship with a usable Date implementation. If somebody could just come up with a standard library for JavaScript that is really widely adopted I think the amount of packages can be cut back dramatically. (1) totally based on gut feeling, not based on hard data
- hn_throwaway_99 7y ago
  Java didn't have a decent date implementation until Java 8. > If somebody could just come up with a standard library for JavaScript that is really widely adopted I think the amount of packages can be cut back dramatically. As this article points out, I think that lodash is that for many people.
  - dep_b 7y ago
    From what I read about it it’s more like syntactic sugar, not something alike the .Net core libraries. Get your JS Core libraries once from a repo, reuse them in every application that uses the same ones
  - toyg 7y ago
    Java has had exact datetime implementations since what, 1.3? 1.2? Sometime in the ‘90s anyway. They weren’t fun to use but they worked fine, had the concept of multiple calendars etc... JS’s version of Date in comparison has always been a toy.
    - hn_throwaway_99 7y ago
      JS's version of Date is pretty much exactly the same as java.util.Date: just a thin veneer around a long representing ms since the epoch. Yes, Java has had Calendar and DateFormat for years, but the API is generally recognized as being pretty horrible (how many bugs were caused by Date and SimpleDateFormat not being thread-safe?) So the Java community coalesced around Joda time, not unlike how the JS community coalesced around moment.js. The big difference is that yes, Java eventually rolled these lessons learned into the java.time API, but now you're effectively stuck with 2 standards, Joda and java.time. Not sure if that's much of an improvement.
- inakarmacoma 7y ago
  Google Apps Script! Heh...
- SahAssar 7y ago
  What makes the js Date implementation unusable in your view? IMO it works pretty okay for most needs.
digianarchist 7y ago
This is what happens with a wafer-thin standard library.
- BiteCode_dev 7y ago
  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?
  - matheusmoreira 7y ago
    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 interfaces should be distributed by default. If something isn't being used anymore, it can be dropped from the standard library while still being available from the repositories.
    - tpetry 7y ago
      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.
      - deleted 7y ago
        [deleted]
  - hombre_fatal 7y ago
    One idea that probably got encoded in the culture is that this code would also have to ship to the client. By having small deps, nobody had to wait around for more advanced tree-shaking (and its idiosyncrasies) to enter the picture.
BiteCode_dev 7y ago
Which is weird. I would have expected have the leftpad scandal that the community would have found a balance. To me, culture is a feature, and despite using JS a lot since it has a monopoly on the browser, the community culture never clicked with me. I often feel like they are reinventing the wheel, not learning from other techs solving the same problems, under and over-engineering, regularly guilty of the XKCD 927 syndrom. Few projects taste integrated, working together, clean. The stacks looked like hacked together. Agreement on best practices and conventions are timidly showing up. It also seems popular tools are just starting to stabilize and the breaking modifications rhythm to slow down. At least more than anywhere else I worked. There is no way I can be objective saying this, but anyone with the same feeling?
- _bxg1 7y ago
  There are several explanations: 1) JavaScript is a first language for many, many new developers, especially the ones not coming from a formal computer science program. This is because it's multi-paradigm, extremely hireable, runs on everything, runs on the web specifically, and other reasons. If you're only going to learn one language, it's a very good and versatile choice. So its community has a lot of inexperienced members. 2) Because it's such a focal point of the industry, it gets a lot of attention from major players as well and has been evolving rapidly in terms of core features. These features usually get tested out first in the form of packages. 3) Being a dynamic language it's very easy to extend and hack. The prototype system even allows you to modify the behavior of its core primitives. 4) The more experienced devs who use it are often dissatisfied with the qualities of the base language, and so take advantage of its flexibility to try and extend it into what they think a good language is (see TypeScript, Ramda, RxJS, etc). The response to the leftpad scandal was for NPM to disallow packages being unpublished once they've been out for 72 hours, which really should've always been the case.
matheusmoreira 7y ago
Why are small packages bad? Independent functions should be versioned and distributed independently. Otherwise we get several utility packages which are nothing but collections of independent functions. Widely used packages should form the basis of a standard library that is distributed with the language itself.
- dragonwriter 7y ago
  > Why are small packages bad? Small, separately maintained packages are bad in a an ecosystem where a final system can incorporate only one version of any given package because it increases the number of opportunities for version conflicts. Now, it's true that there are some other concerns which weigh in favor of packages being at the minimum useful size, but those necessarily also weigh in favor of a package management system which allows each package to isolate its upstream dependencies without constraining it's downstream users. And not just allows, but facilitates it so that it is the norm, so that dependency conflicts aren't a thing.
  - IggleSniggle 7y ago
    I was under the impression that in the npm ecosystem, packages are reused if the version dependencies are compatible, and split if they are not.
- mschuetz 7y ago
  Every separate package adds overhead and another maintainer that you've got to put your trust in. I'd rather have few packages of well trusted maintainers instead of a thousand packages from god knows who. Personally, I've made it a habit to not add anything that requires trivial one liner garbage packages, which amounts to not installing any dependency that uses anything from Jon Schlinkert (so no Webpack). Unfortunately I'm stuck with gulp right now but with the next major rewrite, I'll also get rid of gulp and its 300 dependencies.
  - matheusmoreira 7y ago
    > I'd rather have few packages of well trusted maintainers instead of a thousand packages from god knows who. Then the problem is the fact anybody can submit a package, not small packages. Linux distributions solve this problem by having dedicated maintainers. Users of a distribution trust its maintainers when they use it. Software developers want the complete opposite: language-specific packages, instant and unrestricted package publication, containers, etc. Nobody wants to have to talk to a maintainer in order to get their software included in a distribution. Of course the result ends up being a mess. What if Node's maintainers decided to distribute a curated set of packages alongside Node itself? The size of each individual package wouldn't really matter.

dep_b 7y ago

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 by itself while Javascript doesn't even ship with a usable Date implementation. If somebody could just come up with a standard library for JavaScript that is really widely adopted I think the amount of packages can be cut back dramatically. (1) totally based on gut feeling, not based on hard data

hn_throwaway_99 7y ago
Java didn't have a decent date implementation until Java 8. > If somebody could just come up with a standard library for JavaScript that is really widely adopted I think the amount of packages can be cut back dramatically. As this article points out, I think that lodash is that for many people.
- dep_b 7y ago
  From what I read about it it’s more like syntactic sugar, not something alike the .Net core libraries. Get your JS Core libraries once from a repo, reuse them in every application that uses the same ones
- toyg 7y ago
  Java has had exact datetime implementations since what, 1.3? 1.2? Sometime in the ‘90s anyway. They weren’t fun to use but they worked fine, had the concept of multiple calendars etc... JS’s version of Date in comparison has always been a toy.
  - hn_throwaway_99 7y ago
    JS's version of Date is pretty much exactly the same as java.util.Date: just a thin veneer around a long representing ms since the epoch. Yes, Java has had Calendar and DateFormat for years, but the API is generally recognized as being pretty horrible (how many bugs were caused by Date and SimpleDateFormat not being thread-safe?) So the Java community coalesced around Joda time, not unlike how the JS community coalesced around moment.js. The big difference is that yes, Java eventually rolled these lessons learned into the java.time API, but now you're effectively stuck with 2 standards, Joda and java.time. Not sure if that's much of an improvement.
inakarmacoma 7y ago
Google Apps Script! Heh...
SahAssar 7y ago
What makes the js Date implementation unusable in your view? IMO it works pretty okay for most needs.

digianarchist 7y ago

This is what happens with a wafer-thin standard library.

BiteCode_dev 7y ago
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?
- matheusmoreira 7y ago
  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 interfaces should be distributed by default. If something isn't being used anymore, it can be dropped from the standard library while still being available from the repositories.
  - tpetry 7y ago
    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.
    - deleted 7y ago
      [deleted]
- hombre_fatal 7y ago
  One idea that probably got encoded in the culture is that this code would also have to ship to the client. By having small deps, nobody had to wait around for more advanced tree-shaking (and its idiosyncrasies) to enter the picture.

BiteCode_dev 7y ago

Which is weird. I would have expected have the leftpad scandal that the community would have found a balance. To me, culture is a feature, and despite using JS a lot since it has a monopoly on the browser, the community culture never clicked with me. I often feel like they are reinventing the wheel, not learning from other techs solving the same problems, under and over-engineering, regularly guilty of the XKCD 927 syndrom. Few projects taste integrated, working together, clean. The stacks looked like hacked together. Agreement on best practices and conventions are timidly showing up. It also seems popular tools are just starting to stabilize and the breaking modifications rhythm to slow down. At least more than anywhere else I worked. There is no way I can be objective saying this, but anyone with the same feeling?

_bxg1 7y ago
There are several explanations: 1) JavaScript is a first language for many, many new developers, especially the ones not coming from a formal computer science program. This is because it's multi-paradigm, extremely hireable, runs on everything, runs on the web specifically, and other reasons. If you're only going to learn one language, it's a very good and versatile choice. So its community has a lot of inexperienced members. 2) Because it's such a focal point of the industry, it gets a lot of attention from major players as well and has been evolving rapidly in terms of core features. These features usually get tested out first in the form of packages. 3) Being a dynamic language it's very easy to extend and hack. The prototype system even allows you to modify the behavior of its core primitives. 4) The more experienced devs who use it are often dissatisfied with the qualities of the base language, and so take advantage of its flexibility to try and extend it into what they think a good language is (see TypeScript, Ramda, RxJS, etc). The response to the leftpad scandal was for NPM to disallow packages being unpublished once they've been out for 72 hours, which really should've always been the case.

matheusmoreira 7y ago

Why are small packages bad? Independent functions should be versioned and distributed independently. Otherwise we get several utility packages which are nothing but collections of independent functions. Widely used packages should form the basis of a standard library that is distributed with the language itself.

dragonwriter 7y ago
> Why are small packages bad? Small, separately maintained packages are bad in a an ecosystem where a final system can incorporate only one version of any given package because it increases the number of opportunities for version conflicts. Now, it's true that there are some other concerns which weigh in favor of packages being at the minimum useful size, but those necessarily also weigh in favor of a package management system which allows each package to isolate its upstream dependencies without constraining it's downstream users. And not just allows, but facilitates it so that it is the norm, so that dependency conflicts aren't a thing.
- IggleSniggle 7y ago
  I was under the impression that in the npm ecosystem, packages are reused if the version dependencies are compatible, and split if they are not.
mschuetz 7y ago
Every separate package adds overhead and another maintainer that you've got to put your trust in. I'd rather have few packages of well trusted maintainers instead of a thousand packages from god knows who. Personally, I've made it a habit to not add anything that requires trivial one liner garbage packages, which amounts to not installing any dependency that uses anything from Jon Schlinkert (so no Webpack). Unfortunately I'm stuck with gulp right now but with the next major rewrite, I'll also get rid of gulp and its 300 dependencies.
- matheusmoreira 7y ago
  > I'd rather have few packages of well trusted maintainers instead of a thousand packages from god knows who. Then the problem is the fact anybody can submit a package, not small packages. Linux distributions solve this problem by having dedicated maintainers. Users of a distribution trust its maintainers when they use it. Software developers want the complete opposite: language-specific packages, instant and unrestricted package publication, containers, etc. Nobody wants to have to talk to a maintainer in order to get their software included in a distribution. Of course the result ends up being a mess. What if Node's maintainers decided to distribute a curated set of packages alongside Node itself? The size of each individual package wouldn't really matter.