Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pika: Making it easier to find, publish, install, and use modern packages on npm

pikapkg.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Pika: Making it easier to find, publish, install, and use modern packages on npm

#51

Post by steveklabnik »

johnisgood wrote: post #43
jondubois wrote: post #4

Earlier quoted context omitted.

I don't think that npm itself should be blamed for being too easy to use - That's a good thing in most cases. I think that the main problem is that a couple of years ago some very vocal members of the Node.js community had been promoting a hard-line philosophy around publishing and using tiny modules. The consequence of that is that projects ended up with hundreds of tiny dependencies (and sub-dependencies) which inc…

OK, but this behavior can be observed in both the Python and Rust community, too (maybe other communities as well but I am not in touch with them). Do they promote "a hard-line philosophy around publishing and using tiny modules", too? I had to cargo build a few projects (independently) (e.g. parity-ethereum, c2rust), and it took a while because they had over 300 dependencies. That is a lot. What is the reason for th…

On the spectrum, Rust is not as extreme as npm but is closer to it than not. It just really depends.

Smaller dependencies are easier to maintain, test, and understand. Rust also has a relatively small standard library and so you tend to rely on packages (some produced by the rust project itself) for some things you might use the stdlib for in other languages.

Re: Pika: Making it easier to find, publish, install, and use modern packages on npm

#53

Post by MarvelousWololo »

quantummkv wrote: post #24
gedy wrote: post #21

Earlier quoted context omitted.

Oh please... this is not nearly the case anytime recent. If anything, new CS grads are more prone to reinvent some solution from scratch than to reuse existing solutions. The main issues are that browser tech has advanced rapidly and is/was a non-homogeneous runtime environment. Also JS eco is built from OSS by an enormous pool of developers.

There is a difference between implementing a reinventing a new solution with knowledge of the past mistakes that prevents those mistakes from occurring again and a new solution without knowledge of the past mistakes, which leads to those mistakes being repeated again. In my observation, the JS community tends to go towards the latter.

Could you share some examples of these failures please?

Re: Pika: Making it easier to find, publish, install, and use modern packages on npm

#54

Post by bayesian_horse »

michaelmrose wrote: post #34
bayesian_horse wrote: post #3

Earlier quoted context omitted.

Compared to PyPi it looks like npm packages are much more granular. You'd see the functionality of a popular Python package spread out into multiple npm packages. Both approaches have their advantages. I'd say that for security and reliability, you really need to know what packages you are running. Often you can delegate the responsibility to bigger upstream projects/groups. For example if Facebook works with and on…

There is a cost to relying on someone else's project. If instead of relying on 1 library you rely on 10 this is a pure negative in terms of complexity, risk, communication and potential breakage. Contrary to your statement this is pure disadvantage. "For example if Facebook works with and on React, you can put a good lower bound on the reliability/security of React and the packages it pulls in." I don't think this is…

Bugs and security risk seem to be mostly correlated to the number of lines of code. By splitting a package, keeping the volume constant, the risk shouldn't increase that much. Small packages have less of a chance to cause problems.

Nothing is perfect. NPM and PyPi try to mitigate this problem with security audits and notifications. NPM checks your project for known vulnerabilities at every install.

If you're paranoid, you just don't upgrade packages unless you really need to and audit stuff yourself. That comes with its own costs. As does writing the software all by yourself. Or buying it from commercial vendors with similar tradeoffs applying.

Re: Pika: Making it easier to find, publish, install, and use modern packages on npm

#55

Post by Vinnl »

mrspeaker wrote: post #19
hliyan wrote: post #9

While I'm a big fan of native modules, I find the constant use of the adjective "modern" in new JS project descriptions somewhat disturbing. Being modern in itself is not of any value. If it loads faster, or if it obviates the need for a bundler, or if it makes granular upgrades easier, or if it reduces the amount of configurations or tooling, we should put those benefits first.

"Modern" is another meaningless software-project marketing adjective like "blazingly fast". I'm pretty sure we'll eventually be able to use these buzzwords to perform carbon-dating of old projects. "Hmm, uses the term 'modern' but the README has limited image macro memes... seems like an early 2019 release."

In this case, I think "modern" means "uses ES modules", which have somewhat recently become standardised, but have not (yet) been adopted by all npm packages for various reasons: https://news.ycombinator.com/item?id=19294189

Re: Pika: Making it easier to find, publish, install, and use modern packages on npm

#56

Post by ascorbic »

johnisgood wrote: post #50
true_religion wrote: post #47

Earlier quoted context omitted.

Only the NPM Corp can fix NPM. Anyone can create a different website to aggregate it's results.

Do they allow people to send pull requests though? I know that it does not equal to accepting it, I just wonder if it has been attempted. > Anyone can create a different website to aggregate it's results. Yes, I know, and it is fine. Just wondering.

You can't send pull requests if it's not open source.

Re: Pika: Making it easier to find, publish, install, and use modern packages on npm

#57

Post by johnisgood »

ascorbic wrote: post #56
johnisgood wrote: post #50

Earlier quoted context omitted.

Do they allow people to send pull requests though? I know that it does not equal to accepting it, I just wonder if it has been attempted. > Anyone can create a different website to aggregate it's results. Yes, I know, and it is fine. Just wondering.

You can't send pull requests if it's not open source.

Oh, for some reason I was in the thought that it is. Sorry!

Re: Pika: Making it easier to find, publish, install, and use modern packages on npm

#58

Post by robin_reala »

ravieira wrote: post #52
cm2012 wrote: post #28

Top notch name.

Terrible for Portuguese speakers, as it sounds like a popular alias for penis

So does ‘cock’ in English, yet it also describes the bird. Seems like pikas are still pikas in Portuguese anyway: https://pt.wikipedia.org/wiki/Ochotona

Re: Pika: Making it easier to find, publish, install, and use modern packages on npm

#59

Post by ascorbic »

johnisgood wrote: post #57
ascorbic wrote: post #56

Earlier quoted context omitted.

You can't send pull requests if it's not open source.

Oh, for some reason I was in the thought that it is. Sorry!

There is an open source implementation of the repository, but the website as far as I can tell.

Re: Pika: Making it easier to find, publish, install, and use modern packages on npm

#60

Post by krageon »

MarvelousWololo wrote: post #53
quantummkv wrote: post #24

Earlier quoted context omitted.

There is a difference between implementing a reinventing a new solution with knowledge of the past mistakes that prevents those mistakes from occurring again and a new solution without knowledge of the past mistakes, which leads to those mistakes being repeated again. In my observation, the JS community tends to go towards the latter.

Could you share some examples of these failures please?

The community as a whole has the kind of immaturity that leads to repeated and terrifying security incidents, for one.
Post reply on HN