3 ms·

I'm pretty convinced Ruby and Python's package ecosystem has most of the same problems of JavaScript's but it's just not talked about as much. This article defi

I'm pretty convinced Ruby and Python's package ecosystem has most of the same problems of JavaScript's but it's just not talked about as much. This article definitely has a lot of similarities to npm's MFA implementation and security concerns that have come up.

jacques_chester 4y ago
As it happens, folks from RubyGems, PyPI, npm and others meet regularly to discuss common problems and share ideas: https://github.com/ossf/wg-securing-software-repos https://github.com/ossf/wg-securing-software-repos
- wldcordeiro 4y ago
  That's not very surprising. I think what's surprising is the perception of RubyGems, PyPI, etc is much better than npm's when there are common problems. There's an element of suffering from success but some of the problems have been around in RubyGems and PyPI before Node/npm took off and those were seen as the hot technologies.
  - djur 4y ago
    My experience is that the average npm-based app has significantly more (and smaller) dependencies than a similarly-sized Ruby or Python app, even before factoring in that npm permits using multiple versions of the same dependency at once. This isn't necessarily a bad thing, but it results in a somewhat different set of issues.
rsanheim 4y ago
Not true at all, at least for Ruby. Most larger React projects have _far more_ dependencies_ than an equivalent Ruby project. You could chalk it up to a few things I think: * the JS ecosystem is just much larger - more devs (especially inexperienced ones) means more code and more copy/pasting solutions that rely on `npm install` from the web. * JS has just not been as stable and mature as Ruby or Python until the past couple of years (thanks to ES5/ES6), especially if you consider the browser acceptance of latest ES. * The general explosion of NPM packages that do dumb, trivial shit - see https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd and https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/ https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how... for two examples. * There are at least four major tools to manage dependencies in JS: npm, pnpm, yarn, and yarn 2. This often means you end up with multiple ways teams are handling JS deps in their projects, with all the non-essential complexity that comes with it. In Ruby there is just one way - Bundler. I don't even want to talk about python. * There are more leading frameworks to choose from in JS, which means you have libraries that support all of them, doing things in slightly different ways. Consider a legacy Angular app that updated to React in 2018 and is updating to Svelte or whatever now. If the team hasn't been very disciplined in updating and removing all transitive dependencies through the upgrades, you will inevitably end up with a ton of stuff (is `react-date-wrangler-jobber` used? I still see references to it, but is that page live? who knows!?) in your bundle hanging around and cluttering up your build. I've been updating things across our main React/Rails product at $current_job. Most major dependencies were out of date by 1-2 years. Updating Ruby has been *so much* easier, whereas the React / npm stuff often ends up in a rats nest of conflicting dependencies. And this is after we made a major effort in our build and packaging setup across the board. I do think it is getting better in the npm world, slowly. Ever so slowly.
- itake 4y ago
  > * JS has just not been as stable and mature as Ruby or Python until the past couple of years (thanks to ES5/ES6), especially if you consider the browser acceptance of latest ES. +1. I see way more of my js packages deprecated and renamed than ruby. There hasn't been a huge backwards compatibility issue in ruby since like ~2.7 (ruby 3 and 3.1 were easy), but hunting down which version of node the npm package works on is a huge pain.
- RoddaWallPro 4y ago
  My opinion is that the standard library of JS is so underwhelming that a high % of installs on NPM are for things that the standard library _should_ give you, but doesn't. Date/time, currency, csv, arbitrary precision decimals, int/bigint math, the entirety of lodash, etc. Give JS a fitting standard library, and I'd bet you see the dependency trees shrink by a factor of 10.
- jamesfinlayson 4y ago
  > If the team hasn't been very disciplined in updating and removing all transitive dependencies through the upgrades, you will inevitably end up with a ton of stuff (is `react-date-wrangler-jobber` used? I still see references to it, but is that page live? who knows!?) in your bundle hanging around and cluttering up your build. Ah yep - last week I removed 25 (!) completely unused libraries from a package.json file. > the React / npm stuff often ends up in a rats nest of conflicting dependencies At a previous job we started with Webpack 3, right before Webpack 4 was released, and even months later a bunch of stuff still didn't work with Webpack 4.
borntyping 4y ago
I'd suggest there's a correlation between the size of those package repositories and how much they get talked about. npm has several times the package count of PyPI and RubyGems together, and I don't think that can be accounted for just because it's common to make "micro" JavaScript packages.

jacques_chester 4y ago

As it happens, folks from RubyGems, PyPI, npm and others meet regularly to discuss common problems and share ideas: https://github.com/ossf/wg-securing-software-repos https://github.com/ossf/wg-securing-software-repos

wldcordeiro 4y ago
That's not very surprising. I think what's surprising is the perception of RubyGems, PyPI, etc is much better than npm's when there are common problems. There's an element of suffering from success but some of the problems have been around in RubyGems and PyPI before Node/npm took off and those were seen as the hot technologies.
- djur 4y ago
  My experience is that the average npm-based app has significantly more (and smaller) dependencies than a similarly-sized Ruby or Python app, even before factoring in that npm permits using multiple versions of the same dependency at once. This isn't necessarily a bad thing, but it results in a somewhat different set of issues.

rsanheim 4y ago

Not true at all, at least for Ruby. Most larger React projects have _far more_ dependencies_ than an equivalent Ruby project. You could chalk it up to a few things I think: * the JS ecosystem is just much larger - more devs (especially inexperienced ones) means more code and more copy/pasting solutions that rely on `npm install` from the web. * JS has just not been as stable and mature as Ruby or Python until the past couple of years (thanks to ES5/ES6), especially if you consider the browser acceptance of latest ES. * The general explosion of NPM packages that do dumb, trivial shit - see https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd and https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/ https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how... for two examples. * There are at least four major tools to manage dependencies in JS: npm, pnpm, yarn, and yarn 2. This often means you end up with multiple ways teams are handling JS deps in their projects, with all the non-essential complexity that comes with it. In Ruby there is just one way - Bundler. I don't even want to talk about python. * There are more leading frameworks to choose from in JS, which means you have libraries that support all of them, doing things in slightly different ways. Consider a legacy Angular app that updated to React in 2018 and is updating to Svelte or whatever now. If the team hasn't been very disciplined in updating and removing all transitive dependencies through the upgrades, you will inevitably end up with a ton of stuff (is `react-date-wrangler-jobber` used? I still see references to it, but is that page live? who knows!?) in your bundle hanging around and cluttering up your build. I've been updating things across our main React/Rails product at $current_job. Most major dependencies were out of date by 1-2 years. Updating Ruby has been *so much* easier, whereas the React / npm stuff often ends up in a rats nest of conflicting dependencies. And this is after we made a major effort in our build and packaging setup across the board. I do think it is getting better in the npm world, slowly. Ever so slowly.

itake 4y ago
> * JS has just not been as stable and mature as Ruby or Python until the past couple of years (thanks to ES5/ES6), especially if you consider the browser acceptance of latest ES. +1. I see way more of my js packages deprecated and renamed than ruby. There hasn't been a huge backwards compatibility issue in ruby since like ~2.7 (ruby 3 and 3.1 were easy), but hunting down which version of node the npm package works on is a huge pain.
RoddaWallPro 4y ago
My opinion is that the standard library of JS is so underwhelming that a high % of installs on NPM are for things that the standard library _should_ give you, but doesn't. Date/time, currency, csv, arbitrary precision decimals, int/bigint math, the entirety of lodash, etc. Give JS a fitting standard library, and I'd bet you see the dependency trees shrink by a factor of 10.
jamesfinlayson 4y ago
> If the team hasn't been very disciplined in updating and removing all transitive dependencies through the upgrades, you will inevitably end up with a ton of stuff (is `react-date-wrangler-jobber` used? I still see references to it, but is that page live? who knows!?) in your bundle hanging around and cluttering up your build. Ah yep - last week I removed 25 (!) completely unused libraries from a package.json file. > the React / npm stuff often ends up in a rats nest of conflicting dependencies At a previous job we started with Webpack 3, right before Webpack 4 was released, and even months later a bunch of stuff still didn't work with Webpack 4.

borntyping 4y ago

I'd suggest there's a correlation between the size of those package repositories and how much they get talked about. npm has several times the package count of PyPI and RubyGems together, and I don't think that can be accounted for just because it's common to make "micro" JavaScript packages.