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.<p>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.
>For this new ecosystem to work, we needed a consistent, universal dev experience for every package on the registry.<p>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:<p>> 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.<p>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".<p>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.<p>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 I can give one advice to dev tool makers, it'll be this: Do not build an IDE.<p>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.<p>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.
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.<p>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?
From their about page...<p>> Pika is building a world where third-party libraries can be loaded, cached, and shared across sites.<p>Aren't most browsers disabling/about to disable cross-origin caching?
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.<p>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."<p>In other words, I find this to be an interesting solution, but not something I'd feel comfortable with in enterprise-grade applications.<p>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.<p>Choose for yourself the better choice, and make your own toolkit: <a href="https://kentcdodds.com/blog/concerning-toolkits" rel="nofollow">https://kentcdodds.com/blog/concerning-toolkits</a>
Their about page[0] is interesting.<p>> "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."<p>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.<p>[0]: <a href="https://www.pika.dev/about" rel="nofollow">https://www.pika.dev/about</a><p>[1]: <a href="https://news.ycombinator.com/item?id=21429621" rel="nofollow">https://news.ycombinator.com/item?id=21429621</a>
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.
I think the name is really bad in Brazilian Portuguese<i>. Here "pika"</i>* is a slang for dick. At the same time, it is still the sound Pikachu makes ("pika pika"). So maybe there is no problem.<p>* I don't know about European Portuguese.
<i></i> The correct spelling for the slang would be "pica", but both have the same pronunciation.
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?
I'm going to go the other way on this. I like this idea, but I can see it's not for everyone.<p>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.<p>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?
This website is incredibly confusing and hand-wavy, but from what I've read in the past about Pika, I <i>believe</i> (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.<p>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.<p>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.<p>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 <i>single one</i> 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.<p>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.
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?<p>I'm interested in importing packages directly instead of transpiling stuff in some cases, but I don't see how would that work.
Modules on the web will have a hard time due to:<p>* 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.<p>* 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.<p>* There is no standard for lazy loading, meaning the user need to download everything, even if only 5% is actually required.<p>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.
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.<p>It seems like the niche served by a package manager/cdn that serves native ESM modules is rather small.<p>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.
For those wondering what's wrong with npm, I can recommend this C J Silverio talk <a href="https://www.youtube.com/watch?v=MO8hZlgK5zc" rel="nofollow">https://www.youtube.com/watch?v=MO8hZlgK5zc</a><p>Sadly, as others have noted, this Pika thing does not quite address these issues.
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").
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!
While I don’t think I’ll be able to use Pika, it’s always good to see novel dev tools being released.<p>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.
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.
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.
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.
The homepage looks like it's written for 5 year olds. 100pt font and piles of whitespace do not convey information effectively.<p>Also the only thing I can see without scrolling down is a "give me your email" box. Not a good sign.