5 ms·

Back in 2011ish or so when npm was just getting started and Ruby on rails was all the rage. "Do not repeat yourself" was seen as a gold standard for programmin

Back in 2011ish or so when npm was just getting started and Ruby on rails was all the rage. "Do not repeat yourself" was seen as a gold standard for programming. The end result has been a mess, particularly for npm. There were FAR too many articles talking about how "there's no such thing as too small a dependency" and talks given about how much a virtue it was to create "is-odd" or "is-even" "look you saved 3 lines of code that you don't have to test!" Unfortunately, that compounded with browser of the era (Internet explorer...) having basically 0 support for modern javascript led to a proliferation of dependencies, polyfills, etc that are nearly impossible to remove from the ecosystem. I've not seen a lot of node apologists that are fine with the current ecoystem. The problem is righting the ship is going to be terribly hard. Either existing frameworks/libraries need to go through the effort of saying "Ok, do I really need is-even, let's remove it" or we need new frameworks/libraries to abandon tools and the ecosystem in favor of fatter and fewer dependencies. I think the issue all stems from the fact that before 2010ish, there was one library and one framework, jquery (Ok, there were others... but were there really?) and that added a good 1mb to any webpage. The notion was we do more with less if we had a bunch of smaller deps that didn't need to be brought in.

no_wizard 3y ago
I wonder if there would be any interest from folks for an alternative npm registry that would automatically cleanup dependency chains like this (among other things, possibly), remove polyfills etc. I always thought about something like this, with on the fly manipulation of packages via SWC would be pretty fast I think
- bsimpson 3y ago
  esm.sh kind of does this for livecoding environments (e.g. Codepen/Colab) where you're using <script type=importmap> instead of a bundler.
- nicoburns 3y ago
  I think a better approach would be automated tooling to detect opportunities for cleanup, and then submitting PRs to libraries.
  - rschristian 3y ago
    That only works if the maintainers of the packages are interested in the cleanup -- the maintainer behind some of the packages mentioned in this thread is very much not. They prefer the bloat to incrementing the major version number.
Klonoar 3y ago
jQuery is the one that’s outlasted them all, but yes - there were absolutely other frameworks in use. It also discounts the detour into the Backbone era before Angular and React took off.
- arbol 3y ago
  MooTools springs to mind
  - Klonoar 3y ago
    MooTools, Prototype, Dojo, YUI... what an era. It sometimes feels like part of what we deal with now in the JS world is due to half the crowd not knowing what came before. (Edit: to be clear, I think the other half is responsible for the advancements... so it probably evens out)
    - Izkata 3y ago
      One of the systems I currently work on has all five of those. Which one was in use was developer's choice for pretty much any given page or feature.
- paradox460 3y ago
  I've interacted with devs who still bring in prototype.js Within the last year even
whstl 3y ago
Most people fine with the problems of the ecosystem have financial incentives. Stating that you maintain 800 NPM libraries brings more clout and money than maintaining a foundational one. Even with foundational packages things tend to go wrong. Why add features to an existing package if I can write several plugins? Or even worse in some cases: why use the existing configuration file if I can instead just ask users to install dozens of dummy packages that only exist to trigger a feature in my Core package?
josephg 3y ago
> "Do not repeat yourself" was seen as a gold standard for programming. I remember this era. I’ve been using nodejs before npm existed and so many silly things have happened in that time. I think the core problem the JS ecosystem has always had is that most JS developers are relatively inexperienced. (JS is very beginner friendly and this is the price we pay). I still vividly remember being at nodecamp in 2012 or something listening to someone tell me how great it would be if the entire OS was written in javascript. It didn’t matter how much I poked and prodded him, he couldn’t hear that it might not be an amazing idea. I think he thought it would be easier to reimplement an OS kernel in JS than it would be to just learn C. And there were lots of people around with a sparkle in their eye and those sort of wacky ideas - good or bad. It was fun and in hindsight a very silly time. So yeah, of course some idiot in JS made is-even. And is-odd (which depends on is-even). I see all of this as the characteristic mistake of youth - that we go looking for overly simple rules about what is good and bad (JS good! C bad!) and then we make a mess. When we’re young we lack discernment about subtle questions. When is it better to pull in a library vs writing it yourself inline? When is JS a good or a bad idea? When should you add comments, or tests? And when do you leave them out? Most of the best engineers I know made these sort of stupid philosophical mistakes when they were young. I certainly did. The JS ecosystem just suffers disproportionately from this kind of thing because so many packages in npm are written by relatively new developers. I think that’s a good thing for our industry as a whole. But I also get it when Bryan Cantrill describes JS as the failed state of programming languages.
- TeMPOraL 3y ago
  > The JS ecosystem just suffers disproportionately from this kind of thing because so many packages in npm are written by relatively new developers. I think it also suffers because it grew in the age of Internet and Open Source, which made the problem compounding. Programmers write a lot of stupid code when learning, it's part of the process - but it used to be that the stupidity was constrained to your machine and maybe a few poor souls who ended up reading or using your code. In JS ecosystem, all that stupidity gets published, and ends up worming its way, through dependency chains, into everything.
- beepbooptheory 3y ago
onli 3y ago
Is that with the 1MB a joke? Just in case it's not, jQuery never was that big, not even uncompressed.
- samus 3y ago
  And one could download stripped-down versions with just the features needed. Important especially with jQuery UI since it had quite some heavy components.
tored 3y ago
There was a closely related movement at the time that called for that languages should have minimal "bloat", combined that with importing only what you need down to single functions, it was viewed as the future of programming. I was sympathetic to that idea then, it sounded good in theory, however in practice it was horrible. Today I enjoy coding in "bloated" languages with only a few external dependencies.

no_wizard 3y ago

I wonder if there would be any interest from folks for an alternative npm registry that would automatically cleanup dependency chains like this (among other things, possibly), remove polyfills etc. I always thought about something like this, with on the fly manipulation of packages via SWC would be pretty fast I think

bsimpson 3y ago
esm.sh kind of does this for livecoding environments (e.g. Codepen/Colab) where you're using <script type=importmap> instead of a bundler.
nicoburns 3y ago
I think a better approach would be automated tooling to detect opportunities for cleanup, and then submitting PRs to libraries.
- rschristian 3y ago
  That only works if the maintainers of the packages are interested in the cleanup -- the maintainer behind some of the packages mentioned in this thread is very much not. They prefer the bloat to incrementing the major version number.

Klonoar 3y ago

jQuery is the one that’s outlasted them all, but yes - there were absolutely other frameworks in use. It also discounts the detour into the Backbone era before Angular and React took off.

arbol 3y ago
MooTools springs to mind
- Klonoar 3y ago
  MooTools, Prototype, Dojo, YUI... what an era. It sometimes feels like part of what we deal with now in the JS world is due to half the crowd not knowing what came before. (Edit: to be clear, I think the other half is responsible for the advancements... so it probably evens out)
  - Izkata 3y ago
    One of the systems I currently work on has all five of those. Which one was in use was developer's choice for pretty much any given page or feature.
paradox460 3y ago
I've interacted with devs who still bring in prototype.js Within the last year even

whstl 3y ago

Most people fine with the problems of the ecosystem have financial incentives. Stating that you maintain 800 NPM libraries brings more clout and money than maintaining a foundational one. Even with foundational packages things tend to go wrong. Why add features to an existing package if I can write several plugins? Or even worse in some cases: why use the existing configuration file if I can instead just ask users to install dozens of dummy packages that only exist to trigger a feature in my Core package?

josephg 3y ago

> "Do not repeat yourself" was seen as a gold standard for programming. I remember this era. I’ve been using nodejs before npm existed and so many silly things have happened in that time. I think the core problem the JS ecosystem has always had is that most JS developers are relatively inexperienced. (JS is very beginner friendly and this is the price we pay). I still vividly remember being at nodecamp in 2012 or something listening to someone tell me how great it would be if the entire OS was written in javascript. It didn’t matter how much I poked and prodded him, he couldn’t hear that it might not be an amazing idea. I think he thought it would be easier to reimplement an OS kernel in JS than it would be to just learn C. And there were lots of people around with a sparkle in their eye and those sort of wacky ideas - good or bad. It was fun and in hindsight a very silly time. So yeah, of course some idiot in JS made is-even. And is-odd (which depends on is-even). I see all of this as the characteristic mistake of youth - that we go looking for overly simple rules about what is good and bad (JS good! C bad!) and then we make a mess. When we’re young we lack discernment about subtle questions. When is it better to pull in a library vs writing it yourself inline? When is JS a good or a bad idea? When should you add comments, or tests? And when do you leave them out? Most of the best engineers I know made these sort of stupid philosophical mistakes when they were young. I certainly did. The JS ecosystem just suffers disproportionately from this kind of thing because so many packages in npm are written by relatively new developers. I think that’s a good thing for our industry as a whole. But I also get it when Bryan Cantrill describes JS as the failed state of programming languages.

TeMPOraL 3y ago
> The JS ecosystem just suffers disproportionately from this kind of thing because so many packages in npm are written by relatively new developers. I think it also suffers because it grew in the age of Internet and Open Source, which made the problem compounding. Programmers write a lot of stupid code when learning, it's part of the process - but it used to be that the stupidity was constrained to your machine and maybe a few poor souls who ended up reading or using your code. In JS ecosystem, all that stupidity gets published, and ends up worming its way, through dependency chains, into everything.
beepbooptheory 3y ago

onli 3y ago

Is that with the 1MB a joke? Just in case it's not, jQuery never was that big, not even uncompressed.

samus 3y ago
And one could download stripped-down versions with just the features needed. Important especially with jQuery UI since it had quite some heavy components.

tored 3y ago

There was a closely related movement at the time that called for that languages should have minimal "bloat", combined that with importing only what you need down to single functions, it was viewed as the future of programming. I was sympathetic to that idea then, it sounded good in theory, however in practice it was horrible. Today I enjoy coding in "bloated" languages with only a few external dependencies.