
Pika: Making it easier to find, publish, install, and use modern packages on npm - robin_reala
https://www.pikapkg.com/about
======
mrspeaker
This is really cool - I am a big fan of anything that lets me use less build
tools, dot files, and transpilation steps in my side projects. Thanks to
native modules I have that mostly down to 0: back to just a bunch of html,
css, and javascript files again!

But I usually have to do some re-exporting shenanigans for the one or two
third-party library I really need. This is a great step away from that - thank
you!

------
hliyan
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.

~~~
weego
Ironically I feel like the entire process node/npm is labouring through is
anything but modern. None of these problems are new or unique, unless you
ignore the last few decades of lessons from engineering concerns in other
ecosystems, which unfortunately people seem determined to do.

~~~
quantummkv
> None of these problems are new or unique, unless you ignore the last few
> decades of lessons from engineering concerns in other ecosystems, which
> unfortunately people seem determined to do.

Not intentionally you see. This is completely anecdotal, so take it with
appropriate grains of salt, but I have observed that the majority of people is
the JS ecosystem are not proper students of computer science/development. Most
are either self-taught or come from fast paced bootcamps. So they lack the
historical knowledge of software engineering and basic passing knowledge of
other ecosystems.

Now for the most of us that have spent time studying the field, it is easy to
identify the problems and at least remember that some solutions exist. Most of
the people in JS community do not. So they go through the same process others
have gone through before and land in the same mess.

There is nothing anyone can do about it.

~~~
hliyan
This is a great insight. This kind of explains my constant surprise when I
hear concepts I was taught in university reappear in the JS ecosystem with
different names, and with great fanfare. In a way it's great that these
developers have the ingenuity to rediscover these things on their own, but I
can't help but wonder whether this is a case of those not knowing history
being condemned to repeat it.

~~~
wiredearp
JS developers sometimes have the opposite impression, that computer scientists
have conspired to repeat history in order to make the ecosystem look like
something they know.

~~~
z3t4
CS move forward one generation at a time. The less CS you know the more likely
you are to spot bad practices. And the more naive you are the more likely you
are to make a solution. Sure it might already been solved 30 years ago - but
it might not have been the right time.

------
afj3lmb8zs
ES6 modules are neat, but they are more verbose, not more compact. And they
kind of cripple some of the nifty metaprogramming capabilities that actually
made Node.js cool from a Unix perspective.

------
johnisgood
Excuse my ignorance, but was not it already easy to do these operations? Seems
like yet another centralized package repository with a supposedly visually
appealing interface, where this interface is done just a little bit
differently.

Edit: apparently it is not a package repository, my bad.

Could someone please explain to me what exactly it is and its use cases? Is
this supposed to replace some of the features of npm?

~~~
derimagia
It doesn't look like a package repository. It's just a UI for the npm
repository and some type of build tool.

~~~
johnisgood
At least I got the second part right! :D But yeah, I guess the author was not
content with [https://www.npmjs.com](https://www.npmjs.com)? Is it even
supposed to replace it? I have no idea.

~~~
ascorbic
Seems pretty clear to me: it's a way to search for npm packages that are
published as ES modules. You can't filter by that on npmjs.com, so this does
fill a need. The other parts of the project help you publish packages in ESM
format, which can be a pain to do manually.

~~~
johnisgood
Why not fix npmjs.com instead of scattering things around ad infinitum?

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

~~~
johnisgood
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.

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

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

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

------
z3t4
The nodejs modules are what makes nodejs great. It encourage sharing code and
modularization without complexity.

~~~
yeskia
What do you dislike about ESM in comparison?

~~~
z3t4
ESM had no implementation, and there where already a unofficial standard. Why
did ESM land in ES2015 ? Three years later it still got issues and
implementation is experimental at best.

~~~
growtofill
They are supported by browsers for about two years now:
[https://jakearchibald.com/2017/es-modules-in-
browsers/](https://jakearchibald.com/2017/es-modules-in-browsers/)

~~~
kn8
But why is nobody using that?

Specifically, I would think 99% if stuff being shipped today is bundled with
tools like webpack.

~~~
charrondev
Because it lacks support for bare specifiers and package lookup. There’s also
no dead code elimination or code splitting.

------
cm2012
Top notch name.

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

~~~
robin_reala
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](https://pt.wikipedia.org/wiki/Ochotona)

------
ttsda
Why call this the same as a very popular AMQP library?

[https://github.com/pika/pika/](https://github.com/pika/pika/)

~~~
biggio
As a user of pika it confused me. I wish the author had named it something
other than "pika".

------
saagarjha
From the news I hear (which is quite slanted, I will admit, since I write very
little JavaScript) the issue with npm is that it's too _easy_ to publish
things on npm and use them, which leads to a dependency mess and breakage when
things are removed or get hacked. Is this something that the JavaScript
community needs?

~~~
jondubois
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 increased the attack surface and
introduced their own bugs and/or vulnerabilities.

I think that the Node.js community is wiser now. Vulnerability detection tools
like Snyk.io have been useful in encouraging module authors to remove
unnecessary dependencies from their modules.

Now the trend seems to be to use a fewer modules which offer more
functionality that is more closely matched to the use case.

~~~
johnisgood
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 this phenomenon?

~~~
steveklabnik
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.

