Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speeding up the JavaScript ecosystem – Polyfills gone rogue

marvinh.dev

Post reply on HN
Print view View original

61–70 of 112 posts

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#61

Post by jongjong »

In the early days of the Node.js ecosystem, there was a trend which was all about 'tiny modules'; many developers published tiny 10-line or so modules and people in the community were promoting these tiny modules really hard. It went a bit out of control and a lot of higher level modules were including many of those tiny modules, then those modules were themselves included into other, even higher level modules, etc... The number of modules used by some of these higher level modules/tools/frameworks grew exponentially and we ended up with a lot of unnecessary dependencies.

Each tiny module did just a bit more than it should have done or included just one more dependency than was necessary, sometimes the scope of the module would grow over time and all this added up. Also, different sub-modules used different sub-sub-modules for the same functionality so this caused a lot of duplication in the higher level modules.

For my own open source project, I've always been very careful about which dependencies I use. I favor module authors who try to keep their number of dependencies to a minimum. A lot of times, it comes down to figuring out the correct scope of the module... Most low level libraries should not need to do their own logging; therefore, they should not need to include sub-modules to colorize the bash output; instead, they should just emit events and let higher level modules handle the logging. Anyway there are many cases like that where modules give themselves too much scope.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#62

Post by arthur2e5 »

gibolt wrote: post #35
romellem wrote: post #29

There is some interesting [drama][1] with this, since this article noticeably doesn't mention any PRs they opened to remove some of these older polyfills. The reason those PRs were never opened/merged is the maintainer of many of those libraries [has a strong stance on "breaking" changes][2] in software: > I have developed an intense avoidance for breaking changes in all of my packages, because I don't want to inflic…

Is there not a config for minimum supported JS version? That would appease everyone, while maintaining backwards compatibility. Docs should show the recommended version (modern) and show what options are available to go deeper. Obviously adding those settings for every pollyfill in non-trivial, but burdening everyone with every pollyfill ever is also suboptimal. If anything, this would make cleanup easier going forwa…

There is an "engine"!entry in package.json, and a package manager should be smart enough to not upgrade past what it can. But people tend to not use that sort of dependency flexibility and use lock files…

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#63

Post by arthur2e5 »

These polyfills aren't just large, they're also slow because they never use the native implementation. The good news is that you can replace them all with "overrides" in package.json. That's what nolyfill (https://github.com/SukkaW/nolyfill) does. Oh, and of course the README mentions ljharb.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#64

Post by onli »

cogman10 wrote: post #12
cxr wrote: post #3

You'll never get NPM apologists to acknowledge this. One of their only skills is making non-specific appeals to the necessity of it all (as essential infrastructure) and vague arguments that boil down to "you need to trust the wisdom of the crowds" (and e.g. the fact that it exists and everyone else is using it means that anyone who disputes its value just doesn't understand it—bonus points for them if they manage to…

Back in 2011ish or so when npm was just getting started and Ruby on rails was all the rage. "Do not repeat yourself" was seen as a gold standard for programming. The end result has been a mess, particularly for npm. There were FAR too many articles talking about how "there's no such thing as too small a dependency" and talks given about how much a virtue it was to create "is-odd" or "is-even" "look you saved 3 lines…

Is that with the 1MB a joke? Just in case it's not, jQuery never was that big, not even uncompressed.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#65

Post by deevus »

I haven't got much experience with WASM, but is dependency hell something that WASM completely solves?

All of the cruft that you don't use will get optimised away by the compiler, right?

I'm not aware of any production ready WASM frameworks, but I'm ready for it.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#66

Post by cxr »

spankalee wrote: post #58
cxr wrote: post #52

Earlier quoted context omitted.

> npm is a fairly standard package manager, much like many others Yes. > They both happen to use the word and concept of "version" but to mean different things. Right. I think I covered that adequately. > And vendoring doesn't work for actual packages published to the package repo. What? > If they vendored dependencies then every dependency would be duplicated always, defeating the very purpose of a package manager!…

Man, this isn't hard. The purpose of a packages manager is to allow me to describe the packages and versions that my own package depends on, and download compatible versions of those dependencies and their transitive dependencies in such a way that dependencies are shared and that my runtime can use them. npm does that, as does Cargo, Pub, Gems, pip, etc.

> Man, this isn't hard.

Well, you ducked the question—and what you did say isn't particularly illuminating to anyone who is already familiar with npm and cargo—so it's not at all clear at this point that you're right about that. (Your overall comment actually reads a lot like the sort of thing that I mentioned at the top of this thread: "non-specific appeals to the necessity of it all [...] vague arguments [...] they manage to work in a slight that's designed to paint you, implicitly or explicitly, as a junior".)

I'll ask again: what is the value proposition of npm-like package managers in quantitative terms? Your hypothesis should be falsifiable, if not testable.

If you're having difficulty, we might start here:

> in such a way that dependencies are shared

Why?

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#67

Post by spankalee »

cxr wrote: post #66
spankalee wrote: post #58

Earlier quoted context omitted.

Man, this isn't hard. The purpose of a packages manager is to allow me to describe the packages and versions that my own package depends on, and download compatible versions of those dependencies and their transitive dependencies in such a way that dependencies are shared and that my runtime can use them. npm does that, as does Cargo, Pub, Gems, pip, etc.

> Man, this isn't hard. Well, you ducked the question—and what you did say isn't particularly illuminating to anyone who is already familiar with npm and cargo—so it's not at all clear at this point that you're right about that. (Your overall comment actually reads a lot like the sort of thing that I mentioned at the top of this thread: "non-specific appeals to the necessity of it all [...] vague arguments [...] they…

"Your hypothesis should be falsifiable, if not testable"

Seriously? There are not strange requirements, and you're ducking the issue by trying to force a pseudo-scientific dialog on this. There are language semantics in play, among many other considerations that I'm sure you're well aware of.

But I don't need to convince you, you're already convinced. Have fun.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#68

Post by cxr »

spankalee wrote: post #67
cxr wrote: post #66

Earlier quoted context omitted.

> Man, this isn't hard. Well, you ducked the question—and what you did say isn't particularly illuminating to anyone who is already familiar with npm and cargo—so it's not at all clear at this point that you're right about that. (Your overall comment actually reads a lot like the sort of thing that I mentioned at the top of this thread: "non-specific appeals to the necessity of it all [...] vague arguments [...] they…

"Your hypothesis should be falsifiable, if not testable" Seriously? There are not strange requirements, and you're ducking the issue by trying to force a pseudo-scientific dialog on this. There are language semantics in play, among many other considerations that I'm sure you're well aware of. But I don't need to convince you, you're already convinced. Have fun.

> Seriously?

Yes, seriously.

> There are not strange requirements

Huh?

> you're ducking the issue

I am? How? (What is the issue I'm ducking?)

> There are language semantics in play, among many other considerations that I'm sure you're well aware of.

What?

> I don't need to convince you, you're already convinced.

I don't get it. (What am I already convinced of?) You said this wasn't hard. So why does it seem that way?

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#69

Post by tored »

cogman10 wrote: post #12
cxr wrote: post #3

You'll never get NPM apologists to acknowledge this. One of their only skills is making non-specific appeals to the necessity of it all (as essential infrastructure) and vague arguments that boil down to "you need to trust the wisdom of the crowds" (and e.g. the fact that it exists and everyone else is using it means that anyone who disputes its value just doesn't understand it—bonus points for them if they manage to…

Back in 2011ish or so when npm was just getting started and Ruby on rails was all the rage. "Do not repeat yourself" was seen as a gold standard for programming. The end result has been a mess, particularly for npm. There were FAR too many articles talking about how "there's no such thing as too small a dependency" and talks given about how much a virtue it was to create "is-odd" or "is-even" "look you saved 3 lines…

There was a closely related movement at the time that called for that languages should have minimal "bloat", combined that with importing only what you need down to single functions, it was viewed as the future of programming.

I was sympathetic to that idea then, it sounded good in theory, however in practice it was horrible.

Today I enjoy coding in "bloated" languages with only a few external dependencies.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#70

Post by paradox460 »

Klonoar wrote: post #23
cogman10 wrote: post #12

Earlier quoted context omitted.

Back in 2011ish or so when npm was just getting started and Ruby on rails was all the rage. "Do not repeat yourself" was seen as a gold standard for programming. The end result has been a mess, particularly for npm. There were FAR too many articles talking about how "there's no such thing as too small a dependency" and talks given about how much a virtue it was to create "is-odd" or "is-even" "look you saved 3 lines…

jQuery is the one that’s outlasted them all, but yes - there were absolutely other frameworks in use. It also discounts the detour into the Backbone era before Angular and React took off.

I've interacted with devs who still bring in prototype.js

Within the last year even

Post reply on HN