←back to thread

1369 points universesquid | 2 comments | | HN request time: 0s | source
Show context
stathibus ◴[] No.45169926[source]
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): >>45169990 #>>45169999 #>>45170008 #>>45170014 #>>45170015 #>>45170016 #>>45170038 #>>45170063 #>>45170879 #>>45170926 #>>45170953 #
nine_k ◴[] No.45170008[source]
Having a module for every little trivial thing allows you to only bring these modules inside the JS bundle you serve to your client. If there's a problem in one trivial-thing function, other unrelated trivial things can still be used, because they are not bundled in the same package.

A comprehensive library might offer a more neat DX, but you'd have to ship library code you don't use. (Yes, tree-shaking exists, but still is tricky and not widespread.)

replies(3): >>45170169 #>>45171158 #>>45171236 #
1. skydhash ◴[] No.45170169[source]
Doesn’t the bundler already do tree shaking? Optimizing via dependency listing is very wrong.
replies(1): >>45170314 #
2. tracker1 ◴[] No.45170314[source]
Tree shaking is less than reliable... for it to work well, all the dependencies need to be TS/ESModule imports/exports and even then may not shake out properly.

It helps, but not as much as judicious imports. I've been using Deno more for my personal projects which does have a pretty good @std library, though I do think they should keep methods that simply pass through to the Deno runtime, and should probably support working in Node and Bun as well.