JavaScript's Dependency Problem
danthedev.com
JavaScript's Dependency Problem
1–10 of 16 posts
Re: JavaScript's Dependency Problem
#2I'd like to see an algorithmic grading system that grades every repo publicly on things like: number of (transitive) dependencies, regularity of releases (explicitly not frequency since some things release reliably once a year), test coverage, and so on.
I'd like this to be public so that anyone can enter in a package and check out its score. My thought is that over time this might influence/produce a natural selection of only high quality repos.
My other idea, which is what this post is getting at, is that some group of devs band together to build a "distribution" of reliable JavaScript packages like every Linux distro does with the packages they distribute.
Re: JavaScript's Dependency Problem
#3I'd like to see an algorithmic grading system that grades every repo publicly on things like: number of (transitive) dependencies, regularity of releases (explicitly not frequency since some things release reliably once a year), test coverage, and so on. I'd like this to be public so that anyone can enter in a package and check out its score. My thought is that over time this might influence/produce a natural selecti…
I like the last idea best. It's not an unreasonable amount of work -- every project basically does this on their own now. One or two dedicated people could do a great job.
Re: JavaScript's Dependency Problem
#4I'd like to see an algorithmic grading system that grades every repo publicly on things like: number of (transitive) dependencies, regularity of releases (explicitly not frequency since some things release reliably once a year), test coverage, and so on. I'd like this to be public so that anyone can enter in a package and check out its score. My thought is that over time this might influence/produce a natural selecti…
A recently announced tool called Socket is trying to do exactly that scoring approach :
Re: JavaScript's Dependency Problem
#5I'd like to see an algorithmic grading system that grades every repo publicly on things like: number of (transitive) dependencies, regularity of releases (explicitly not frequency since some things release reliably once a year), test coverage, and so on. I'd like this to be public so that anyone can enter in a package and check out its score. My thought is that over time this might influence/produce a natural selecti…
A recently announced tool called Socket is trying to do exactly that scoring approach : https://socket.dev/
I've seen some of these and my angle is separate from security. So far all the grading systems have been focused on security and not code quality, including not counting (transitive) dependencies.
It's not just better packages I want but fewer of them.
The tools like socket.dev could of course choose to incorporate stuff like this.
Also, to make permanent progress it's important the the grades all be public. Not sure if socket.dev is public.
Re: JavaScript's Dependency Problem
#6I'd like to see an algorithmic grading system that grades every repo publicly on things like: number of (transitive) dependencies, regularity of releases (explicitly not frequency since some things release reliably once a year), test coverage, and so on. I'd like this to be public so that anyone can enter in a package and check out its score. My thought is that over time this might influence/produce a natural selecti…
Some of these data points are captured by Synk advisor https://snyk.io/advisor/
Re: JavaScript's Dependency Problem
#7The problem is that there is little incentive to "clean up" and move away from the bottomless trough of is-even type packages... similarly, how many front-end tools require one of the many utility packages that effectively just wrap some minor functionality around document.querySelector? Is the problem inexperienced developers? (the article talks about this as well)
I'm also curious how many HN readers and JS devs in general were, at some point, told to "not reinvent the wheel", instructed (by a professor, by a mentor...) to use libraries wherever possible, and extrapolated that out to today, where so many devs have found a way to justify requiring is-even (there are hundreds, thousands of packages like this)...
Re: JavaScript's Dependency Problem
#8The problem is that there is little incentive to "clean up" and move away from the bottomless trough of is-even type packages... similarly, how many front-end tools require one of the many utility packages that effectively just wrap some minor functionality around document.querySelector? Is the problem inexperienced developers? (the article talks about this as well) I'm also curious how many HN readers and JS devs in…
I don't think we talk enough about the downsides of DRY.
Reinventing the wheel for the sake of reinventing the wheel (not-invented-here) is a problem, but reinventing it for the sake of learning more about wheels is a big deal.
I suppose many developers reach for libraries because they're more confident that the libraries will implement things correctly/more efficiently than they could. But if they keep reaching for libraries (instead of trying to write an `isEven` function themselves) then they never really improve either.
Re: JavaScript's Dependency Problem
#9As a developer, I love JavaScript ecosystem for some of theses drawback of this package manager.
I'm be able to quickly publish a library on NPM and this is great IMO. Few years ago, I tried to do it for Maven in Java and it was a nightmare.
> We don't need two million packages. We probably don't even need two thousand.
I don't think so. There are many tools, frameworks and libraries in JS and I love that. I learn from all of them and this is exciting. I don't want an ecosystem with only JQuery to do all I want. Sometimes I may use Vue.js, sometimes Angular or React... and that's great.
Re: JavaScript's Dependency Problem
#10As a developer, I love JavaScript ecosystem for some of theses drawback of this package manager. I'm be able to quickly publish a library on NPM and this is great IMO. Few years ago, I tried to do it for Maven in Java and it was a nightmare. > We don't need two million packages. We probably don't even need two thousand. I don't think so. There are many tools, frameworks and libraries in JS and I love that. I learn fr…
Why is it great to be able to publish a package quickly? You may be a smart programmer who only releases production quality, bug-free, vulnerability-free code, but is it a good thing that it is easy for inexperienced developers or malicious users to be able to publish packages at the same ease/speed?
No one wants an ecosystem with only jQuery, but there's a middle ground somewhere before you get to 2 million packages. Competing frontend frameworks fit comfortably within that space. I just don't want a world where there are 16 competing packages that all implement a slider in React.
There's a huge difference if you only use npm for personal projects, too. The consequences of picking unmaintained/undocumented/insecure/buggy software are much, much lower if you can afford to rewrite/throwaway in a weeks time.