> A majority of the dependencies for modern frontend development are only used during development<p>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!".<p>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.<p>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.
Not Javascript's dependency problem, but NPM's dependency problem. You don't <i>need</i> to use NPM to build things in JS — it's perfectly feasible to manually load just the scripts you need, and avoid build steps, frameworks, and dependencies.
As a developer, I love JavaScript ecosystem for some of theses drawback of this package manager.<p>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.<p>> We don't need two million packages. We probably don't even need two thousand.<p>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.
The 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)<p>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)...
I'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.<p>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.<p>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.
I have a slightly different spin on how JavaScript ended up where we are: <a href="https://erock.io/2021/03/27/my-love-letter-to-front-end-web-development.html" rel="nofollow">https://erock.io/2021/03/27/my-love-letter-to-front-end-web-...</a>