4 ms·

One of the author’s points it the thing that makes me crazy about the JS ecosystem “... find a package ... it might depend on hundreds of other packages, with d

by DLA 6y ago

One of the author’s points it the thing that makes me crazy about the JS ecosystem “... find a package ... it might depend on hundreds of other packages, with dependency trees stretching ten or more levels deep...” I cannot count the number of times when I’ve installed a package and got >500 or >1000 packages as dependencies. Just today I installed ‘alptail’ a simple set of components using AlpineJS and TailwindCSS (I love both!) but it npm installed 1314 packages! For a simple set of maybe a dozen components. This is madness. How do we make this better? Maybe we need more support from tooling to understand just what is being used down the tree of trees of trees? Maybe as lib writers we should seek to implement our own supporting functions (within limits, of course) rather than having a first reaction “let’s go grab XYZ for that” and inherit XYZ’s entire dep tree. Not sure what the answer is but what we have today is a beautiful mess (love/hate it). Thanks for letting me vent a bit. I feel better. But this really bothers me.

dboreham 6y ago
I believe you are looking in the wrong place for the source of the problem. The true source is the people who established and maintain the norms within this ecosystem. They just don't care that all manner of things are either broken or insecure or both. They have other concerns. I'm not sure what those concerns are, but I'm very sure that we will never ever persuade them that their culture is a bad one and so the problems outlined above will never be fixed in place. Hence some sort of B-Arc or nuke from orbit approach will be necessary.
stevebmark 6y ago
I just wonder who cares? At all? What is "better"? Reinventing wheels instead of relying on open source, battle tested code? Also alptail isn't an npm package? https://github.com/danieljpalmer/alptail https://github.com/danieljpalmer/alptail
- marcus_holmes 6y ago
  This "reinventing the wheel" concept has to die. Writing your own code is not "reinventing the wheel". It's what we do. A lot of times writing a new implementation is faster in the long run (more focused, less obscure, easier to maintain). Open source code is often not "battle tested" in your environment for your use case. And if there is a problem, getting it fixed can be a nightmare. It's like I'm making a go-cart, and making some nice appropriately-sized matching wheels for it, and someone comes along insisting I don't "re-invent the wheel" and use these four mismatched truck wheels instead. Yes, I'll save time making the wheels. But the rest of the project is screwed.
  - DLA 6y ago
    > Writing your own code is not "reinventing the wheel". It's what we do. A lot of times writing a new implementation is faster in the long run (more focused, less obscure, easier to maintain). So much agreement. We often will rewrite smaller sets functions or other code for the express purposes of trimming dependencies, understanding what the code does, and having the opportunity to adopt it into our codebase with a fresh re-look at implementation, adding comments, etc. > Open source code is often not "battle tested" in your environment for your use case. And if there is a problem, getting it fixed can be a nightmare. Again. Agree with you strongly. Just because something as been available in npm does not automatically mean battle tested. There's a ton of broken/poor code out there.
- DLA 6y ago
  I care. I don't want an exponential growth in dependencies each time I use a top level library. 1314 packages is crazy for a small set of web components. How could one ever read/review 1314 libs to have a passing familiarity of the deps one just took on? Oh you just npm install and DON'T look through what you got. That, friend, is scary. If that's the case I'd invest in some packet capture training :) if I were you. Right, alptail is not an npm package. Clone the repo then npm install to see the tree of pain grow itself. Not picking on alptail here. Just my most recent WTF experience with getting way more deps than seems reasonable, by a mile.
ypcx 6y ago
> How do we make this better? I do believe that a great library (package) is either self contained (e.g. lodash, moment, etc.) or has a minimum number of dependencies on other such libraries. I think we can think of dependencies as adding to the code size and code complexity of the library which uses them, and then derive the quality of said library from those metrics. JavaScript is great for writing code which can do a lot, and writing it fast, and I think this power shouldn't be misused to manufacture a lot of small libraries with a lot of dependencies. Perhaps we should use something like Github Gists or Stack Overflow answers for that. This why I am personally gravitating towards Deno (https://deno.land/ https://deno.land/) now -- it has a nice set of base APIs and modules, and it allow me to pull a self-contained library straight from the CDN.

by DLA 6y ago

dboreham 6y ago

I believe you are looking in the wrong place for the source of the problem. The true source is the people who established and maintain the norms within this ecosystem. They just don't care that all manner of things are either broken or insecure or both. They have other concerns. I'm not sure what those concerns are, but I'm very sure that we will never ever persuade them that their culture is a bad one and so the problems outlined above will never be fixed in place. Hence some sort of B-Arc or nuke from orbit approach will be necessary.

stevebmark 6y ago

I just wonder who cares? At all? What is "better"? Reinventing wheels instead of relying on open source, battle tested code? Also alptail isn't an npm package? https://github.com/danieljpalmer/alptail https://github.com/danieljpalmer/alptail

marcus_holmes 6y ago
This "reinventing the wheel" concept has to die. Writing your own code is not "reinventing the wheel". It's what we do. A lot of times writing a new implementation is faster in the long run (more focused, less obscure, easier to maintain). Open source code is often not "battle tested" in your environment for your use case. And if there is a problem, getting it fixed can be a nightmare. It's like I'm making a go-cart, and making some nice appropriately-sized matching wheels for it, and someone comes along insisting I don't "re-invent the wheel" and use these four mismatched truck wheels instead. Yes, I'll save time making the wheels. But the rest of the project is screwed.
- DLA 6y ago
  > Writing your own code is not "reinventing the wheel". It's what we do. A lot of times writing a new implementation is faster in the long run (more focused, less obscure, easier to maintain). So much agreement. We often will rewrite smaller sets functions or other code for the express purposes of trimming dependencies, understanding what the code does, and having the opportunity to adopt it into our codebase with a fresh re-look at implementation, adding comments, etc. > Open source code is often not "battle tested" in your environment for your use case. And if there is a problem, getting it fixed can be a nightmare. Again. Agree with you strongly. Just because something as been available in npm does not automatically mean battle tested. There's a ton of broken/poor code out there.
DLA 6y ago
I care. I don't want an exponential growth in dependencies each time I use a top level library. 1314 packages is crazy for a small set of web components. How could one ever read/review 1314 libs to have a passing familiarity of the deps one just took on? Oh you just npm install and DON'T look through what you got. That, friend, is scary. If that's the case I'd invest in some packet capture training :) if I were you. Right, alptail is not an npm package. Clone the repo then npm install to see the tree of pain grow itself. Not picking on alptail here. Just my most recent WTF experience with getting way more deps than seems reasonable, by a mile.

ypcx 6y ago

> How do we make this better? I do believe that a great library (package) is either self contained (e.g. lodash, moment, etc.) or has a minimum number of dependencies on other such libraries. I think we can think of dependencies as adding to the code size and code complexity of the library which uses them, and then derive the quality of said library from those metrics. JavaScript is great for writing code which can do a lot, and writing it fast, and I think this power shouldn't be misused to manufacture a lot of small libraries with a lot of dependencies. Perhaps we should use something like Github Gists or Stack Overflow answers for that. This why I am personally gravitating towards Deno (https://deno.land/ https://deno.land/) now -- it has a nice set of base APIs and modules, and it allow me to pull a self-contained library straight from the CDN.