Pika/web: Web Apps Without the Bundler • Hacker News Board

Re: Pika/web: Web Apps Without the Bundler

#61

Post by rhizome » Wed, Mar 20, 2019, 3:15 AM UTC

s_y_n_t_a_x wrote: post #44

GordonS wrote: post #42

Earlier quoted context omitted.

OTOH, if you use a "standard" library from a CDN, it's quite possible that the end user already has it cached.

That never really works out in practice when there's so many versions and then you're at the disposal of a public CDN, which can be the bottleneck, especially when it's critical code. Sure you can fallback to local copies, but that just means your app hung there for X amount of time, and the added complexity of adding fallback logic. Plus if you look at the size of these libraries, especially utility libraries (date-…

That never really works out in practice

So glad this was such dominant practice and advice for the last 10 years. I wonder for how many of those influential practictioners have known it's more of a lazy include than clever cache reuse. Cargo culting writ larger than most.

Re: Pika/web: Web Apps Without the Bundler

#62

Post by curry-castaway » Wed, Mar 20, 2019, 3:35 AM UTC

segphault wrote: post #21

This solution pulls in 155 packages from npm, including multiple versions of bullshit packages like "kind-of" that it can't deduplicate. One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. The reason that JavaScript build tooling is so complex and introduces so much overhead is that the ecosystem's culture is fun…

> One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies.

Just trying to understand, is this a bad thing?

Someone else made an open source CLI spinner library which also uses other people's existing open source libraries. This saves a lot of time and gives developers many good options.

Should Pika write and maintain its own custom CLI spinner animations? Are you saying the CLI spinners should be standardized in the next version of ECMAScript itself?

How is this worse than the same thing written in Python, for example? (I mainly use javascript, so maybe I haven't been exposed to the kinds of alternatives you're thinking about.)

Re: Pika/web: Web Apps Without the Bundler

#63

Post by intertextuality » Wed, Mar 20, 2019, 4:09 AM UTC

curry-castaway wrote: post #62

segphault wrote: post #21

This solution pulls in 155 packages from npm, including multiple versions of bullshit packages like "kind-of" that it can't deduplicate. One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. The reason that JavaScript build tooling is so complex and introduces so much overhead is that the ecosystem's culture is fun…

> One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. Just trying to understand, is this a bad thing? Someone else made an open source CLI spinner library which also uses other people's existing open source libraries. This saves a lot of time and gives developers many good options. Should Pika write and maintain…

It’s bad because this leads to a standard React project having over 2,000 dependencies.

The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them.

What happens when a common package breaks? What happens if it gets hijacked and becomes a security vector that’s impossible to spot because it’s loaded as the 567th package in a dependency tree?

The answer here is to have a strong stdlib where do you don’t need to pull in 3rd party packages all the time for trivial things, and not including a million small packages in every single project.

Re: Pika/web: Web Apps Without the Bundler

#64

Post by curry-castaway » Wed, Mar 20, 2019, 4:21 AM UTC

intertextuality wrote: post #63

curry-castaway wrote: post #62

Earlier quoted context omitted.

> One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. Just trying to understand, is this a bad thing? Someone else made an open source CLI spinner library which also uses other people's existing open source libraries. This saves a lot of time and gives developers many good options. Should Pika write and maintain…

It’s bad because this leads to a standard React project having over 2,000 dependencies. The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. What happens when a common package breaks? What happens if it gets hijacked and becomes a security vector th…

> The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them.

So the problem is the sheer number of dependencies? What is a reasonable upper limit?

Yes, javascript should continue to standardize commonly used features, but avoiding dependencies doesn't seem to be a solution.

If anything, more dependencies are a good sign because they imply that other people have spent more time and effort on a solution than anything you'll be able to hand-roll for single-use.

It sounds like the root issue here is just dependency management. If our package managers were solving this issue well enough, there should be no practical difference between 2 big dependencies with significant functionality (and more code to review) or 20 tiny, easy-to-review dependencies.

Re: Pika/web: Web Apps Without the Bundler

#65

Post by yardstick » Wed, Mar 20, 2019, 5:26 AM UTC

curry-castaway wrote: post #64

intertextuality wrote: post #63

Earlier quoted context omitted.

It’s bad because this leads to a standard React project having over 2,000 dependencies. The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. What happens when a common package breaks? What happens if it gets hijacked and becomes a security vector th…

> The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. So the problem is the sheer number of dependencies? What is a reasonable upper limit? Yes, javascript should continue to standardize commonly used features, but avoiding dependencies doesn't see…

From a security perspective, minimising dependencies is preferred. I have to review at least monthly all our dependencies for published vulnerabilities and new versions.

We don’t allow automatic upgrading of packages/dependencies due to the risk of malicious code making it in (see https://www.npmjs.com/advisories for examples). Yeah there are companies that will help manage your vulnerability process but it’s still a lot of overhead and only grows as the number of dependencies grows.

There’s also the whole left-pad mess from a few years back which shows you always need local archived copies of any dependencies you use.

Re: Pika/web: Web Apps Without the Bundler

#66

Post by toastal » Wed, Mar 20, 2019, 5:40 AM UTC

rtfeldman wrote: post #49

pier25 wrote: post #32

Earlier quoted context omitted.

I've said before and I'll say it again, we wouldn't be in this mess if we had a decent standard library and language to begin with.

> a decent standard library and language This is what a lot of people love about Elm: it's a lovely language with a first-rate standard library. The Elm ecosystem is smaller than the JS ecosystem, but of course that's a hard requirement of a nicer foundation. More info: https://elm-lang.org

Elm still needs `andMap` for ``/`apply` on basically all core packages though.

Re: Pika/web: Web Apps Without the Bundler

#67

Post by toastal » Wed, Mar 20, 2019, 5:43 AM UTC

Touche wrote: post #36

anonytrary wrote: post #34

Earlier quoted context omitted.

Sorry if this is a dumb question -- but that means you don't write ES6?

It doesn't mean that, they might only support ES6 browsers (even IE11 has some ES6 support).

The support is really shallow, but using `let` and `const` is still superior to `var` where applicable.

Re: Pika/web: Web Apps Without the Bundler

#68

Post by jaabe » Wed, Mar 20, 2019, 5:59 AM UTC

curry-castaway wrote: post #62

segphault wrote: post #21

This solution pulls in 155 packages from npm, including multiple versions of bullshit packages like "kind-of" that it can't deduplicate. One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. The reason that JavaScript build tooling is so complex and introduces so much overhead is that the ecosystem's culture is fun…

> One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. Just trying to understand, is this a bad thing? Someone else made an open source CLI spinner library which also uses other people's existing open source libraries. This saves a lot of time and gives developers many good options. Should Pika write and maintain…

It’s fine from a development perspective where the job is to make something work.

It’s horrifying from an operations perspective where the job is to make sure everything works.

Developers can afford to ignore looking into dependencies, operations need to make sure every dependency is functional and safe.

If you write a piece of C# using the standard .Net library you can be fairly sure it’s safe and sound. If you write something using 2000 JS packages, you have to read through every one of them to be sure.

Re: Pika/web: Web Apps Without the Bundler

#69

Post by [deleted] » Wed, Mar 20, 2019, 7:02 AM UTC

intertextuality wrote: post #63

curry-castaway wrote: post #62

Earlier quoted context omitted.

> One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. Just trying to understand, is this a bad thing? Someone else made an open source CLI spinner library which also uses other people's existing open source libraries. This saves a lot of time and gives developers many good options. Should Pika write and maintain…

It’s bad because this leads to a standard React project having over 2,000 dependencies. The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. What happens when a common package breaks? What happens if it gets hijacked and becomes a security vector th…

[deleted]

Re: Pika/web: Web Apps Without the Bundler

#70

Post by intertextuality » Wed, Mar 20, 2019, 7:06 AM UTC

curry-castaway wrote: post #64

intertextuality wrote: post #63

Earlier quoted context omitted.

It’s bad because this leads to a standard React project having over 2,000 dependencies. The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. What happens when a common package breaks? What happens if it gets hijacked and becomes a security vector th…

> The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. So the problem is the sheer number of dependencies? What is a reasonable upper limit? Yes, javascript should continue to standardize commonly used features, but avoiding dependencies doesn't see…

There is an enormous difference between 2 large packages and 20 small ones. I can see the main authors more clearly, and not have to worry about 20 different packages being compromised. Your statement makes no sense. More packages does not, in any way, shape, or form, correlate to “better quality”. The sole thing it shows is that the author pulled in more packages. That’s it. Whether it’s good or bad or secure or not secure is only determined by analysis. The author could easily have been super lazy and pulled in 18 small packages instead of writing small helper functions manually, etc. There is no defensible argument for more packages and bloat. None. As I said above, the core lib should focus on providing functionality so pulling in a fancy spinner library means you pull in ONE library, not 20.