Most of the packages on NPM are complete garbage - most not all - (and I say this as a full time JS dev who actually likes JS), liking the technology does not have to mean liking what people do with it, and JS is the worst, both in terms of the crap on NPM and the web.
Although I would look for similar examples elsewhere to understand where it is all headed. And one of those could be the rise and adoption of the JVM. There are a bunch of old dependencies, multiple repositories (compared to just one popular npmjs), a couple of build tools (ant, maven, gradle) compared to npm, yarn, then multiple languages (invented for somewhat similar reasons as Typescript). One thing is sure that the dependencies stay somewhere for-almost-ever, and all else kind of evolves around it.
It seems that the main problem at the moment is the developer (me, you, everyone) who instead of writing 20 lines of code uses a dependency that has 10 other transient ones. You cannot fix it but rather challenge those situations at work and reduce the tech debt for good. Maybe there should be a build tool that throws errors depending on the amount of dependencies. Maybe there should be a frontend framework which will only need 10 dependencies for the helloworld instead of 1500; otherwise we kind of think that if a boilerplate template has 1500 deps then surely adding another 100 will not make much harm.
Its value is less about the existing dependency tree of libraries and more about how many apps directly depend on libraries that are npm-hosted.
There are many 200+ kloc apps out there making millions/yr each that deeply depend on libraries and frameworks hosted in npm.
I generally think the NPM ecosystem is pretty cool, but I have noticed that even simple stuff like creating a RESTful service doesn't seem to have stablised in the ways I would have expected given node's target audience, and you end up writing a lot of the boilerplate yourself. Hopefully this will result in hundreds of replies telling me how I should be doing it, but even the fact that it's not trivial to find that out is a sign of a fragmented ecosystem.
And don't do anything. I'm amazed by how often I read the source for a package I'm interested in, only to find it's about 10 or 20 lines of code.
The convenience of adding a package means that if you're not sure how to do something, you can easily just add a package to do it rather than figuring out how to do it yourself. A lot of the time, you can just read the source and adapt it rather than installing the package.
Having reusable code wrapped into packages is basic software engineering.
Although some people will then complain about the size of the library...
Exporting out one method at a time is pretty absurd.
This is also an opinionated subject, and as with most things in life there is a balance somewhere in between the two extremes. However the NPM packages you refer to (and yes I have seen the <10 line offenders you refer to) are clearly at a stupid end of extremely useless shared code that amount to the most trivial stackoverflow JS examples.
In response to the sibling comment on duplication: all I can say is that it cuts both ways, deduplication to the extreme also has downsides: when someone changes that code you don't control, it now affects a large number of dependencies that the author may not care about. But even ignoring those issues and assuming you package-lock everything and never look back, extreme de-duplication in general can result in highly illegible code due to a lack of holistic view: whether it's achieved with thousands of tiny external packages or thousands of tiny 3 line functions in the same file - many have covered this topic in detail before, deduplication for deduplication sake never ends well, abstractions always have a cost.
Also: if you're porting from Node, the only things that really have to change are the system/IO API calls. The import style is a bit different but that could pretty much be automated. It's still just TypeScript at the end of the day; your core logic will be the same.
Except not because lots of people prefer to write JavaScript and those other JVM languages are usually less verbose rather than more verbose.
I think this shows the lack of willingness to write a vanilla, all-compatible javascript. Also it seems people use new features without understanding how those get compiled to a lower version.
Sorry when I meant vanilla I did not mean ES9.
Plus, aren't Deno libs compatible with Node libs?
Maybe but who cares when your code does not execute instantly on Lambda and requires you to use GaalVM to convert bytecode to binary. Besides you have a lot of people who would say Kotlin is better.
Javascript, like Python wins here. Well Javascript kind of wins because it is interpreted but devs do not use it directly but rather with a bundler/compiler.
> Plus, aren't Deno libs compatible with Node libs
Not really, if your dependency relies on say `https` module then it'll not work on Deno as it does not have it. And in the case of Deno modules, they are not on `npm` to begin with but even if you import them then they are written in Typescript.
Furthermore Node has its own maintenance/risk issues in production systems (think permissions), and Deno reduces those with custom built runtimes.
I cannot see it replacing Node though. Node has created a vast ecosystem that includes modules (npmjs), client side bundlers (eg webpack), serverside frameworks (eg express), etc. But because Deno is solving some of the issues for those who run sensitive code in production (eg Lambda functions) it'll most likely gonna become another VM on the public cloud providers' list.
All in all Javascript interpreter is becoming something like a JVM. Everyone wants to use it but without writing vanilla Javascript.