As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?
replies(11):
I have no hope of this ever happening and am abandoning the web as a platform for interactive applications in my own projects. I’d rather build native applications using SDL3 or anything else.
It's perfectly possible to build web apps without relying on npm at all, or by being very selective and conservative about the packages you choose as your direct and transitive dependencies. If not by reviewing every line of code, then certainly by vendoring them.
Yes, this is more inconvenient and labor intensive, but the alternative is far riskier and worse for users.
The problem is with web developers themselves, who are often lazy, and prioritize their own development experience over their users'.
It started as CommonJs ([1]) with Server-side JavaScript (SSJS) runtimes like Helma, v8cgi, etc. before node.js even existed but then was soon totally dominated by node.js. The history of Server-side JavaScript btw is even longer than Java on the server side, starting with Netscape's LifeScript in 1996 I believe. Apart from the module-loading spec, the CommonJs initiative also specified concrete modules such as the interfaces for node.js/express.js HTTP "middlewares" you can plug as routes and for things like auth handlers (JSGI itself was inspired by Ruby's easy REST DSL).
The reason for is-array, left-pad, etc. is that people wanted to write idiomatic code rather than use idiosyncratic JS typechecking code everywhere and use other's people packages as good citizens in a quid pro quo way.
[1]: https://wiki.commonjs.org/wiki/CommonJS
Edit: the people crying for an "authority" to just impose a stdlib fail to understand that the JS ecosystem is a heterogeneous environment around a standardized language with multiple implementations; this concept seems lost on TypeScripters who need big daddy MS or other monopolist to sort it all out for them
Not hating on the author but I doubt similar compromise would happen to Facebook or Google owned package.
People have done, but the ecosystem has already engrossed around the current status quo and it's very hard to get rid of habits.
At this point, it’s just status-quo and lazyness
At a time small JS libraries were desired, and good library marketing approach, but nowadays simple sites ship megabytes of without a care.
In particular this developer is symptomatic of the problem of the NPM ecosystem and I've used him multiple times as an example of what not to do.
It's not unique in this sense, yet others manage to provide a lot more in their stdlib.
It's not that you need a "big daddy". It's that the ecosystem needs a community that actually cares about shit like this vulnerability.
Apache Commons helper libraries don't import sub libraries for every little thing, they collect a large toolbox into a single library/jar.
Why instead do people in the javascript ecosystem insist on separating every function into it's own library that STILL has to import helper libraries? Why do they insist on making imports fractally complex for zero gain?
It started with browsers giving you basically nothing. Someone had to invent jQuery 20 years ago for sensible DOM manipulation.
Somehow this ethos permeated into Node which also basically gives you nothing. Not even fundamental things like a router or db drivers which is why everyone is using Express, Fastify, etc. Bun and Deno are fixing this.
Or you can code it in. Mega packages can be very stable. Think SDL, ffmpeg, ImageMagick, Freetype...There's usually a good justification for dropping something alongside a wide deprecation windows. You don't just wake up and see the project gone. It's not like the escape codes for the unix terminal are going to change overnight.
What is this crap statement?
So you want type-checking because it helps you catch a class of errors in an automated way, and suddenly you have a daddy complex and like monopolies?
Claiming this says a lot more about you than people who use TypeScript.
UUID v7 for example is unstable and one would be pretty confident in that not changing at this stage.
Many unstable functions have less churn than a lot of other “stable” packages. It’s a standard library so it’s the right place to measure twice before cementing it forever.