This is important to note. I think we have to separate non-dev dependencies and dev dependencies. The attitude should be different. One is embedded in the product you deliver the other is only used locally to make the product. No one would say that we should start writing our C++ compiler by hand because "dependencies!".
I think this is an important strength of javascript: the tooling infrastructure. Its ability to embed everything you need into your package.json makes it so easy to start working on a project. I'm old enough to remember the weeks spent trying to get all the licenses, accounts created, software installed and configured in order to just start compiling a project.
This being said, we should also be careful about the tool we're using. If you want to use mustache with express, do not install the dependencies that link them together (mustache-express). Just write the 4 lines of code you need to adapt one to the other, so that you have a better understanding of what's going on and when something fails, you'll not be lost in a sea of unreadable JS code you didn't write.
Coincidentally one of my previous posts was about a no tool approach. https://danthedev.com/web-dev-without-tools/
Precisely. Which is why it's NPM's dependency problem, not JS's. Avoid NPM and no dependency problems (well, fewer anyway).
Liked your no tool article, but I laughed at this bit: "Traditionally, using other people's code has required some combination of npm and yarn to download those modules". NPM is only 12 years old (and Yarn is newer) — that's less than half the age of JS. No, 'traditionally' you just viewed the source and copied the code you wanted, or went to a project page and downloaded the script.
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.
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.
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)...
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.
Pet project usually get a lot more attention, but rewriting existing libraries is not exactly fun and will require maintenance when made public, so that does not happen often.
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.
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.
