
Pika – A JavaScript package registry for the modern web - jacobwg
https://www.pika.dev/registry
======
Etheryte
There are many issues with the status quo of NPM, but I don't see this
addressing any of the real issues. Code formatting is not a problem that a
package registry should address; having a custom editor simply to use a
registry is absurd. If those are the problems you wanted to address, you
could've just written a plugin for a few common editors.

The real issues that a package repository should address are security and
verifiability. Is this package trustworthy? Is the latest minor version bump
safe to use? What about dependencies deep down the tree? How to automatically
detect when a package has been hijacked? How to handle benign package
takeovers, e.g. package owner deciding to give ownership to maintainers. Etc
etc.

~~~
Hamuko
How are you even going to force a single way of formatting when JS devs can't
even agree on including/excluding semicolons?

~~~
fiddlerwoaroof
Tools like prettier have gone a long way to standardizing formatting in JS.

~~~
paulddraper
Agreed. Prettier is de facto standard for new projects.

It lets you choose quote character, indentation size, and that basically it.

~~~
michaelcampbell
Well...
[https://prettier.io/docs/en/options.html](https://prettier.io/docs/en/options.html)

~~~
paulddraper
> \--tab-width

> \--single-quote

I mentioned.

> \--use-tabs

Relates to the "indentation width."

> \--print-width

Yes, that's another big user-configurable parameter.

> \--trailing-comma

This exists only for JS version compatibility.

> \--no-semi

> \--no-bracket-spacing

> \--arrow-parens

Yeah, those are there too.

\---

But that's _really_ it for JavaScript formatting options. Like I said, this
produces very standardized code in the ecosystem.

Compare to clang-format (which suports JavaScript):
[http://releases.llvm.org/5.0.0/tools/clang/docs/ClangFormatS...](http://releases.llvm.org/5.0.0/tools/clang/docs/ClangFormatStyleOptions.html)

~~~
onion2k
clang-format is nice but it's closer to eslint than Prettier. It does a lot
more than just enforcing what the code looks like.

------
unlinked_dll
>For this new ecosystem to work, we needed a consistent, universal dev
experience for every package on the registry.

That's the most absurd sentence thing I've seen in awhile, editing is
orthogonal to package management. But others have that thread covered. This
got my attention:

> Pika publishes each package directly from source, so malicious or hacked
> authors can't skip code review or sneak malicious code unnoticed into the
> registry.

I don't see how injecting yourself in the middle solves the problem, since
exfiltrating data in the background from a downstream app is both necessary
for some services and hard to identify as "bad".

What I'd like to see in a registry is a registration fee per project (or pay
per publish), non-anonymous registration (provide a government issued ID and
mandatory 2FA), delayed deployment after publishing, and aggressive but open
auditing. Plus org/user namespacing.

Basically if you have an environment where a bad actor has to pay money, steal
someone's identity, and takes awhile before they can even verify their attack
has been successful - you'll cover a huge chunk of the attack surface area.

~~~
ChristianBundy
> Basically if you have an environment where a bad actor has to pay money,
> steal someone's identity, and takes awhile before they can even verify their
> attack has been successful - you'll cover a huge chunk of the attack surface
> area.

If you have an environment where a good actor has to pay money, provide their
passport name with proof of identity, and has to put up with artificial
deployment delays, I think you'll miss out on a huge chunk of good actors.

I'm not convinced that it's possible to outsource your trust and audit
decisions to some third-party system. We should be scaling at the speed of
actual human trust, not giving up our privacy to companies or our security to
randos.

~~~
unlinked_dll
There's plenty of places/ways to distribute software anonymously. And
depending on software from an anonymous identity with no trust that the
registry verified who they were or if subsequent publications came from the
same entity is an attack vector.

There is a time and place for anonymity, but I don't think a dependency
registry is one of them (most of the time). And I think if you're going to
make a _new_ registry, such verification is a way to make yourself different.

~~~
icebraining
> if subsequent publications came from the same entity

The way you do that is by having signed packages. Gov IDs don't help with
that, unless the registry verified the ID every time you published an update,
which is impractical (unless you have a smart ID card, but most governments
don't issue those).

------
jeswin
If I can give one advice to dev tool makers, it'll be this: Do not build an
IDE.

People are attached to IDEs like no other tool; they won't leave their
customizations, key bindings, themes and switch to an unproven alternative.
This isn't true all the time, but holds 99.9% of the time.

Also, despite being fairly familiar with the JS ecosystem I am unable to make
out what Pika does from the landing page. You probably need to do a better job
of explaining the product.

~~~
pgl
> _I am unable to make out what Pika does from the landing page_

This seemed fairly succinct:

> _Pika is a new kind of package registry for the modern web_

Not sure what "Universal JavaScript" means though, and I don't understand why
a registry would need an IDE.

~~~
dgellow
What is “modern web” here? That can mean so many things.

~~~
ratww
They explain it right after the "modern web" phrase:

> 100% ESM

Here's some additional info:
[https://www.pika.dev/about](https://www.pika.dev/about)

------
burlesona
I don’t mean to be snarky, but when seeing “make our neat package registry
easy to use we wrote our own custom IDE for you to develop in,” I can’t help
but think this project has jumped the shark.

Does Pika really expect devs to be so drawn to their package registry that
they want to write in Pika Code instead of their existing editor of choice? Is
publishing packages in JavaScript really that hard?

~~~
ratww
I think the whole point of Pika was to not require a complex local development
environment for coding websites. Installing a bunch of stuff is probably the
#1 or #2 main complaint about modern frontend and a huge roadblock for
newbies.

By using their CDN you can already make pages and apps with just a text
editor, without node, npm, webpack, etc.

I think it makes sense for them to try to improve the experience of package
creation and publishing too.

~~~
dgellow
Why would those hypothetical newbies need to publish packages? That’s not
something you should care about before quite some time when you’re learning a
language.

Or is the idea to have a registry full of tutorial packages?

~~~
ratww
I never said that newbies would or should be publishing packages.

Pika CDN and @pika/cli can potentially make newbies' lives easier, but it
doesn't mean that every project under the Pika umbrella is aimed exclusively
at newbies.

~~~
dgellow
Fair enough.

------
Nullabillity
From their about page...

> Pika is building a world where third-party libraries can be loaded, cached,
> and shared across sites.

Aren't most browsers disabling/about to disable cross-origin caching?

~~~
jdnenej
It was rarely useful anyway. I saw some stats showing even with jQuery it was
extremely unlikely users already had a copy of the version of jQuery from the
same CDN cached.

~~~
t-writescode
Wasn’t that the point of Google sharing a copy of jquery for everyone?

------
JMTQp8lwXL
The problems Pika aims to solve don't sound like registry problems, and I
think we could run into trouble as a consequence. For example, I've written
code where I ES6 import an SVG file that, using webpack loaders, automatically
becomes a React component.

A tool like Pika isn't going to understand that without making broad
assumptions of my project's structure. This is more than just, oh "Do I need
ES Modules or Common JS?" or "That file needs to transpiled since it uses the
spread operator, and I happen to be rendering on IE 11, which doesn't support
that."

In other words, I find this to be an interesting solution, but not something
I'd feel comfortable with in enterprise-grade applications.

Just learn how bundlers and transpilers work. It's going to be easier to do
that, then understand why Pika won't do what you need it to, having to go
through yet another layer of abstraction. I've been disappointed by tools in
the past that try to abstract away the "difficult" parts of maintaining a
webpack.config.js and babel.config.js file. I truly believe it is more
beneficial for developers to learn these things, instead of trying to be
ignorant of them and then fighting with a tool like Pika or a toolkit that
doesn't meet your needs.

Choose for yourself the better choice, and make your own toolkit:
[https://kentcdodds.com/blog/concerning-
toolkits](https://kentcdodds.com/blog/concerning-toolkits)

------
firloop
Their about page[0] is interesting.

> "Pika is building a world where third-party libraries can be loaded, cached,
> and shared across sites" ... "With ESM and cross-origin caching, we can
> create a world where sites can share cached dependencies."

This is an interesting angle on a package registry. The goal seems difficult
to achieve as well since the common web cache as we know it is dying[1]. It
seems like we'd need some sort of "dependency" support for web browsers if
we'd ever want to achieve it.

[0]: [https://www.pika.dev/about](https://www.pika.dev/about)

[1]:
[https://news.ycombinator.com/item?id=21429621](https://news.ycombinator.com/item?id=21429621)

------
fenwick67
Totally off-topic but, is there a word for this style of marketing copy/design
language with lots of deep blues, rounded edges, primary colors and geometric
shapes? Atlassian and Digital ocean use something very similar.

~~~
folkhack
Flat design I'd say is the closest, although there's a ton of ways you could
describe this. I'd also describe it as minimalist + a strong focus on readable
typography with space to "breathe". Other sites like Digital Ocean have a
great focus on simple iconography that enhances their message.

All-in-all I _love_ that design trends have gone this direction as I think
it's a friendlier and more efficient means to convey information =)

Years ago skeuomorphism was a popular trend which is to try to make things 3D
representing real-world objects (buttons, dials, etc). Although it's still
highly prevalent in UI design, we've really backed off of the trend. A great
example of this is early vs. current iOS. I mention this because there's a ton
of great "skeuomorphism vs flat design" stuff out there discussing the ethos
of sites like this.

------
supercasio
I think the name is really bad in Brazilian Portuguese _. Here "pika"_* is a
slang for dick. At the same time, it is still the sound Pikachu makes ("pika
pika"). So maybe there is no problem.

* I don't know about European Portuguese. __The correct spelling for the slang would be "pica", but both have the same pronunciation.

~~~
dagurp
It means vagina in Icelandic

~~~
jacurtis
Well at least it is equally offensive to everyone then

~~~
godDLL
По-русски it is a "lance". So maybe a bit fallic.

------
thiht
I'm not really fond of the fact that the "About Us" page doesn't actually say
anything about them. Who are you and why should I trust you?

------
bobm_db
I'm going to go the other way on this. I like this idea, but I can see it's
not for everyone.

I like to do some Javascript coding with my son on his Chromebook, and having
a development environment is a hard problem for us to solve for some reason.

Having a webpage that just spins up VSCode and allows us to publish and test
in a registry might be just what we need, no?

~~~
ratww
I'm the same as you.

I know lots of devs are different, but if I could do all my work in a web app
and never install any development software in my laptop, I'd do it in a
heartbeat.

~~~
kaetemi
Cloud9?

------
_bxg1
This website is incredibly confusing and hand-wavy, but from what I've read in
the past about Pika, I _believe_ (though I had trouble finding this clearly
stated) its key feature is automatic conversion of third-party JavaScript
modules to the ES6 (here referred to as ESM) module syntax.

For those who aren't familiar, JavaScript has two distinct module syntaxes
(and several variations on those). Nodejs brought its own when it came on the
scene, and then later browsers standardized on a new one for the web. The two
are incompatible in some pretty nasty ways (the former is a runtime function,
the latter is fully static). So standard practice is to use a bundler like
Webpack or Browserify to concatenate your code and all its dependencies into a
single JS file (with modules being properly scoped, artificially, through
functions scopes and other tricks) for use in web browsers. Basically, this
allows browsers to avoid dealing with however all your modules may import each
other; you can even mix both syntaxes in one project. The browser just sees
one big file.

The problem is, a) this makes it virtually impossible to use any dependencies
from NPM on the front-end without a bundler, which means a minimum required
amount of configuration and tooling, and b) you lose out on some potential
caching benefits because files that may not change much can't be
distinguished.

So why doesn't everyone just use the new modules syntax so that code can be
loaded in the browser, as separate modules, without bundling? Because if even
a _single one_ of your NPM dependencies is still in the other syntax, you're
up a creek. It's like the IPv6 problem: until everyone has it, nobody does.

So projects like (I think) Pika have cropped up to try and address this. If it
really does auto-convert packages to the new modules syntax, that eliminates
the biggest reason to use build tooling in a modern JS project. You could
theoretically get away with having no build process at all.

------
fiatjaf
How can I use this? I see stuff like importing directly from a CDN? What does
that mean? I could just call `import` in my source JavaScript without
transpiling? I also see `npm install` stuff, so what's the difference?

I'm interested in importing packages directly instead of transpiling stuff in
some cases, but I don't see how would that work.

~~~
fiatjaf
Ok, got it: [https://www.pika.dev/cdn](https://www.pika.dev/cdn)

I'll start using this thing.

------
z3t4
Modules on the web will have a hard time due to:

* Not good enough HTTP2 support in browsers. Browser will for example download pushed files twice, once when pushed, then again when imported, and not caching the pushed files.

* Many developers prefer to brake their code up into small files, meaning there will be a lot of hops until the entire dependency tree has been resolved.

* There is no standard for lazy loading, meaning the user need to download everything, even if only 5% is actually required.

As much as a hate bundlers, and would like to see more code moduleability on
the web, bundlers get the job done using code splitting, deduplication etc.

------
manigandham
While using basic imports instead of a build step is nice, unfortunately most
projects of any size or complexity end up requiring a build stage for
components, css, static assets, optimization for the non-modern browsers and
more.

It seems like the niche served by a package manager/cdn that serves native ESM
modules is rather small.

The code editor seems unnecessary too, but it's built on VSCode so it can
probably be repurposed into an extension easily. Better tools for publishing
packages are needed though, and I like how it helps setup a modern environment
for creating packages.

------
mst
Serious question: What does this provide that unpkg doesn't?

------
drej
For those wondering what's wrong with npm, I can recommend this C J Silverio
talk
[https://www.youtube.com/watch?v=MO8hZlgK5zc](https://www.youtube.com/watch?v=MO8hZlgK5zc)

Sadly, as others have noted, this Pika thing does not quite address these
issues.

------
tannhaeuser
A custom JavasScript-DSL for this seems to conflict with established CommonJS
conventions for browser-packages/assets distributed on npm (ie. to use
"browser" instead or in addition to "main" entries in package.json), and also
with ES6 modules ("esm").

------
mc3
Seeing a new package manager makes me feel uneasy! Although NPM is not
perfect, being able to NPM i all the things is nice, now that bower is defacto
dead and you just use webpack instead. But if this takes off there will be
choice again. Choice = JS fatigue!

~~~
Aeolun
Why not yarn? That’s been around a really long time to give you fatigue.

~~~
1_player
Though I agree with your point, yarn 1.0 was released in Sep 2017.

2 years is really not a long time, though it seems to be for the JS ecosystem.

------
disposedtrolley
While I don’t think I’ll be able to use Pika, it’s always good to see novel
dev tools being released.

I’m keen to see how Pika Code improves the end to end dev experience by
presumably being tightly integrated with deployment. Remind me of Dark in a
way.

------
jug
This looks like something designed to be paid when early access is over? I
thought Visual Studio Code's extension API was so extensive by now that
something like this could be delivered as an extension instead.

------
flaque
If this handled the "build & config" of publishing packages and made the whole
process effectively 0-config, I could see myself using it. But there's a lot
here that I don't want.

~~~
bfred_it
With GitHub templates and npm’s init/create packages you already have options
without having to use an editor.

Examples:

    
    
        npm init esm
        npm init react-app
    

[https://docs.npmjs.com/cli/init](https://docs.npmjs.com/cli/init)

------
navs
Pika code has some nice features. I don't see myself switching away from
PHPStorm/Visual Studio Code but the quick start feature seems like a great
addition.

------
k__
While this seems to be an horrible attempt to replace NPM, how are the other
attempts going?

------
p1necone
The homepage looks like it's written for 5 year olds. 100pt font and piles of
whitespace do not convey information effectively.

Also the only thing I can see without scrolling down is a "give me your email"
box. Not a good sign.

