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

51–60 of 112 posts

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#51

Post by vinnymac »

tedunangst wrote: post #48
smallnamespace wrote: post #45

The reason libraries call polyfills directly is because it's impolite for a library to change global scope underneath you. Usually it's the top-level application's author who chooses and configures polyfills. Now one may reasonably ask, why doesn't the library just call Object.defineProperties directly, and tell the user to install the appropriate polyfill? I'm going to guess that a library that Just Works after an n…

But why are we polyfilling a function that exists in every version of node? When did this code not just work after installation that it required a polyfill?

My best guess is that the code was used in non-node environments.

It wasn’t and isn’t uncommon to pull down a dependency from npm and expect it to work in multiple runtimes.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#52

Post by cxr »

spankalee wrote: post #42
cxr wrote: post #30

Earlier quoted context omitted.

I'm happy to criticize NPM the tool. The whole thing is designed as a second, crummier version control system that lives in disharmony with and on top of your base-level version control system (so it can subvert it). It's a terrible design. There's basically at most one reasonable use for npm: as a glorified download manager, i.e. to quickly fetch a module by name (right before you check it in to version control with…

How is npm a version control system? npm is a fairly standard package manager, much like many others, pretty good even. I don't know of anyone who says that package managers and source control solve the same problems. They both happen to use the word and concept of "version" but to mean different things. Yes, some projects vendor in their dependencies into their source control system, but they must either manually ve…

> 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!

Yes. Alternatively:

Please clearly articulate the purpose of a package manager (in the sense of the term when it's used to describe npm and others). See if you can work it out so that you can state it in the form of a testable hypothesis (i.e. ideally in quantitative terms like MBs/GBs of disk space used, or network transit, or time to fetch—or anything that you think accurately reflects what you consider to be the value proposition that npm fulfills and which we can use to evaluate it in scenarios where it would or would not be a good fit).

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#53

Post by nicoburns »

no_wizard wrote: post #13
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…

I wonder if there would be any interest from folks for an alternative npm registry that would automatically cleanup dependency chains like this (among other things, possibly), remove polyfills etc. I always thought about something like this, with on the fly manipulation of packages via SWC would be pretty fast I think

I think a better approach would be automated tooling to detect opportunities for cleanup, and then submitting PRs to libraries.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#54

Post by chatmasta »

Sometimes it can be a security vulnerability to call a polyfill instead of the now available default implementation. For example, this 2018 bug [0] in the Grammarly Chrome Extension had a much wider impact due to its reliance on a fetch polyfill that was able to make requests (via XHR) to origins that native fetch could not.

I suppose in that case you could argue the real bug is in the XHR API, but it only affected the extension because the extension was using a fetch polyfill that relied on it in functions that could be triggered by an external page.

[0] https://hackerone.com/reports/389108

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#55

Post by rschristian »

nicoburns wrote: post #53
no_wizard wrote: post #13

Earlier quoted context omitted.

I wonder if there would be any interest from folks for an alternative npm registry that would automatically cleanup dependency chains like this (among other things, possibly), remove polyfills etc. I always thought about something like this, with on the fly manipulation of packages via SWC would be pretty fast I think

I think a better approach would be automated tooling to detect opportunities for cleanup, and then submitting PRs to libraries.

That only works if the maintainers of the packages are interested in the cleanup -- the maintainer behind some of the packages mentioned in this thread is very much not. They prefer the bloat to incrementing the major version number.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#56

Post by proxyon »

potsandpans wrote: post #31
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…

Ljharb is harmful to the ECMAScript community

He's frequently on a powertrip and confidently wrong about so many things. For instance he's one of the people who perpetuate the "Javascript is fast and you don't need to optimize anything" falsehood. No wonder he's bringing in 100 polyfills into everyone's project. He thinks JS is C.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#57

Post by technion »

beepbooptheory wrote: post #41
josephg wrote: post #28

Earlier quoted context omitted.

> "Do not repeat yourself" was seen as a gold standard for programming. I remember this era. I’ve been using nodejs before npm existed and so many silly things have happened in that time. I think the core problem the JS ecosystem has always had is that most JS developers are relatively inexperienced. (JS is very beginner friendly and this is the price we pay). I still vividly remember being at nodecamp in 2012 or som…

I thought is-even/is-odd were satirical? Granted, satire echoing these same points... but, you know, just for-the-record.

Although it's unclear, every time someone provides a one liner there are staunch not satire arguments about "covering edge cases you didn't think of" and I disagree. Look at the actual code: https://github.com/i-voted-for-trump/is-odd/

There's a "tested edge case" where you can check isOdd('1') and it will work - to me the code is already wrong, isOdd(STRING) should throw. The correct solution is to use Typescript and assert the input is a number.

The Number.isSafeInteger check is an interesting one. Yes, it's not "safe" to work with a number outside this but no doubt something in the function would be broken before an is-odd check if it was relied upon.

Often the edge case someone else catered to is something counter to my expectation. I would rather write two lines of code myself and be aware of the behaviour.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#58

Post by spankalee »

cxr wrote: post #52
spankalee wrote: post #42

Earlier quoted context omitted.

How is npm a version control system? npm is a fairly standard package manager, much like many others, pretty good even. I don't know of anyone who says that package managers and source control solve the same problems. They both happen to use the word and concept of "version" but to mean different things. Yes, some projects vendor in their dependencies into their source control system, but they must either manually ve…

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

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#59

Post by potsandpans »

silverwind wrote: post #38
potsandpans wrote: post #31

Earlier quoted context omitted.

Ljharb is harmful to the ECMAScript community

I'm thankful for his work, but I do agree, this polyfill madness has to stop.

I am _appreciative_ that people like him exist, because -- personal feelings aside -- we do need people who have his level of dedication in the open source space.

My only interactions with ljharb have been in TC39. More often than not when looking at issues he's active in, I find myself wanting a level of maturity and thoughtfulness that just isn't there.

His contributions are neither novel or very compelling. He's more of an open-source bureaucrat than an engineer or a developer, yet he is currently steering several major TC39 proposals. I've seen him shutdown or sidetrack valid input and criticisms in all of them. The vibes I get from his behavior are akin to him being a member of "the cool kid club" -- wanting to maintain that ingroup/outgroup boundary very tightly.

He really should just get out of the standards/committee space entirely for the time being, and get some coaching on leadership skills before reentering. I realize this is super negative. Still on the ropes whether or not this feedback belongs in the public space.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#60

Post by forgotmypw17 »

ComputerGuru wrote: post #14

I maintain a few JavaScript libraries that I manually verify compatibility against IE6 (and have lints to catch violations). I manually polyfill a few necessities and quality-of-life improvements up top in the script. Out of curiosity, I removed my polyfills and tried swc and babel both, followed by an eslint pass, and the results were absolutely atrocious. Everything gets polyfilled, even stuff that has been support…

Thank you for supporting IE6. I also maintain some JS and ensure compatibility with older browsers. Someone out there still wants to use it, whether it's an old machine with nostalgic value, the only machine they happen to have available, or just retro-computing enthusiasts, and I take pride in accommodating them. Good on you.
Post reply on HN