Live data from Hacker News

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

pikapkg.com

21–30 of 60 posts

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

#21
post #12

Earlier quoted context omitted.

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.

> 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. Mos…

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.

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

#22
post #16

Earlier quoted context omitted.

> 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. Mos…

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.

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

#24
post #21

Earlier quoted context omitted.

> 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. Mos…

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.

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

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

I think it's simply a way to distinguish between old style JS ecosystems and new. It encompasses a range of benefits and lessons learned in JS. Of course not everyone is going to agree that the "modern" way is the right reaction to the problems of the past but most active JS programmer will have a good idea what it means.

C++ has a similar issue. There's a very distinct difference between C++11 and what came before. And C++20 could be another big shift (especially with modules). Modern has a useful meaning, even if it's fuzzy and temporal.

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

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

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

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

#27
post #18
post #12

Earlier quoted context omitted.

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.

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

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

#29
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

Sure, but though I'm not that familiar with CPython and pypy, I don't think there are many situations where those runtimes have as varying and sometimes conflicting requirements as Node and the browser. I'd guess the differences are more similar to the differences among the different browsers alone, which already are different runtimes by themselves.

That said, even if those runtimes are as different as Node and the browser are, it's the interplay of that restriction in combination with the other characteristics I mentioned that make this a new challenge in its own right.

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

#30
post #11

Earlier quoted context omitted.

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.

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.

Post reply on HN