Live data from Hacker News

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

pikapkg.com

31–40 of 60 posts

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

#31
post #26

Earlier quoted context omitted.

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

Jest, FB's JS testing framework, is described as blazing fast but is actually twice as slow as Jasmine (or was at some point). If twice as slow is blazing fast, I don't know what twice as fast is. I do know 'blazing fast' is meaningless. It's just deceptive. For reference: https://github.com/facebook/jest/issues/6694

OT, but I was using Jest and switched back to Mocha. Since my tests are nothing special and 100% browser env they load instant. Should have done sooner

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

#32
post #30

Earlier quoted context omitted.

They are supported by browsers for about two years now: https://jakearchibald.com/2017/es-modules-in-browsers/

But why is nobody using that? Specifically, I would think 99% if stuff being shipped today is bundled with tools like webpack.

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

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

#34

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?

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 true. You could easily depend on something that react pulls in which they later drop months before it turns into a vector for malware.

I don't see how trust translates down the dependency graph AT ALL.

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

#35
post #16

Earlier quoted context omitted.

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.

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.

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.

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

#36
post #27
post #18

Earlier quoted context omitted.

Problems that Node/npm deals with that are relatively new/unique: - Distributing modules that work in both the browser as well as on the back-end - Working with and developing an ecosystem for a language that wasn't really developed for years and years, was still missing quite a bit of functionality, and then suddenly gained a lot of traction - That language having to catch up on years and years of developments in co…

> Distributing modules that work in both the browser as well as on the back-end You could say that they are two different runtimes, think CPython / pypy

The python distribution infrastructure lags far behind that of javascript.

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

#37
post #26

Earlier quoted context omitted.

Jest, FB's JS testing framework, is described as blazing fast but is actually twice as slow as Jasmine (or was at some point). If twice as slow is blazing fast, I don't know what twice as fast is. I do know 'blazing fast' is meaningless. It's just deceptive. For reference: https://github.com/facebook/jest/issues/6694

OT, but I was using Jest and switched back to Mocha. Since my tests are nothing special and 100% browser env they load instant. Should have done sooner

I made liberal use of jest's expectation framework and module mocking. Migrating is 'doable' but at this stage in the project I can't justify the delay on the deadline.

I've got about 200 integration tests too with a package that builds itself into an OS dependent state so I'm stuck running things in a VM. Probably easier to mark up the tests so I can run unit tests most of the time. That should make things bearable.

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

#38
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?

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

#39
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.

Whenever I see that word, I am reminded of a book I have titled Modern Welding --- published in the late 60s, so I guess it has always been a pretty meaningless adjective; but it does seem the JS (and web development) community in general likes to use that word a lot.

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

#40

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…

It doesn't look like a package repository. It's just a UI for the npm repository and some type of build tool.
Post reply on HN