111–120 of 279 posts
The real issue the Balkanization of JavaScript programs. The `rate-map` package is essentially one line of code: start + val * (end - start); https://github.com/shinnn/rate-map/blob/90c234c9/index.mjs#L...
Earlier quoted context omitted.
Honestly, I think the reliability of those packages are not guarded by these people, but rather by the corresponding communities of those packages. If one of the community failed to secure its package from malicious people, these people at debian are not going to be able to stop it. Thus, those packages are still guarded by a huge community.
Why do you think this? OSes like Debian don’t just pull packages from upstream automatically. Packages have actual maintainers affiliated with the OS, not the upstream community, and it’s those maintainers who build packages for the OS repos.
Earlier quoted context omitted.
Why do you think this? OSes like Debian don’t just pull packages from upstream automatically. Packages have actual maintainers affiliated with the OS, not the upstream community, and it’s those maintainers who build packages for the OS repos.
Not entirely true, Debian actually made OpenSSL less secure once: https://www.debian.org/security/2008/dsa-1571
I merely said that Debian packages are built, uploaded, and vended by Debian package maintainers, not by upstream. Whether that makes them more trustworthy or less is a different question.
Earlier quoted context omitted.
I honestly don't understand why people use packages like this. If I need this functionality, I will simply write my own. Plus, I will never able to find this specific package. I guess PureScript uses this because its author is also the author of rate-map.
I’ll give you one: it’s code already written and tested by > 1 person, edge cases already figured out. Saves you time. The gains are small but quickly add up. This is why lately I’ve been a fan of very extensive standard libraries (like Crystal has) - its like having a huge repository but vetoed by the same team and without any of the package management drawbacks.
There are costs to these micro-libraries that outweigh the gains. This code is trivial; there aren’t really edge cases to be worked out.
NPM gets a lot of hate for it's dependency managemnet, but I'm not sure what a solution would be to this problem. - They can't currate packages, or else that friction will drastically slow down the ecosystem (1000's of packages get published everyday). - They can't remove/disable packages (most of the time) , or dependencies will no longer be strictly immutable. - They can't disable sub-dependencies, or else this wou…
After 10 years of nodejs I can honestly say I wouldn’t mind the friction. NPM is a wasteland of abandoned packages and reinventing the wheel. They never solved discovery so you have 500x implementations of the exact same thing. Around 2015 we passed the point where looking for the “right” package takes longer than writing your own.
If I want to work with JSON, I use Newtonsoft.JSON. If I want an ORM I'll use Dapper (lightweight) or Entity Framework. So many libraries that would you need if you're using Java or JS is just built in to the standard library.
I know it's not a 100% fair comparison, since I am biased. Part of it also might be because .NET is younger and less widely used, but I feel it's pretty true. Though, Python has ton of open source support and is better in this regard.
Lies, more lies and broken promises!
I wouldn't use the words "malicious" or "exploit" wrt this... It's more like, I dunno, trolling on planet JavaScript? I feel like there should be a big Twitter fight about it...
Earlier quoted context omitted.
I’ll give you one: it’s code already written and tested by > 1 person, edge cases already figured out. Saves you time. The gains are small but quickly add up. This is why lately I’ve been a fan of very extensive standard libraries (like Crystal has) - its like having a huge repository but vetoed by the same team and without any of the package management drawbacks.
> The gains are small but quickly add up. There are costs to these micro-libraries that outweigh the gains. This code is trivial; there aren’t really edge cases to be worked out.
The real issue the Balkanization of JavaScript programs. The `rate-map` package is essentially one line of code: start + val * (end - start); https://github.com/shinnn/rate-map/blob/90c234c9/index.mjs#L...
Earlier quoted context omitted.
But it doesn't work for libraries people will be using in development. Often you are waiting for a handful of packages to introduce specific features or bug fixes and need them the moment they are available. NPM isn't user space, it's dev space. Timeliness is the maxim.
I’m not a JS developer so maybe I’m missing something, but how do you use a library during development and not use it in production? In the C++ world, I can’t imagine a situation where you would need to depend on, for example, libjpg while developing, but not need to read JPEG files in prod/end-user-space.