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

41–50 of 112 posts

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#41

Post by beepbooptheory »

josephg wrote: post #28
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…

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

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#42

Post by spankalee »

cxr wrote: post #30
whstl wrote: post #27

Earlier quoted context omitted.

The parent is not criticising NPM the tool/registry, but rather the ecosystem and culture.

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 verify package version compatibility or use a package manager like npm to help them do it. And vendoring doesn't work for actual packages published to the package repo. If they vendored dependencies then every dependency would be duplicated always, defeating the very purpose of a package manager!

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#43

Post by phire »

josephg wrote: post #28
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…

> "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 still vividly remember being at nodecamp in 2012 or something listening to someone tell me how great it would be if the entire OS was written in javascript.

That reminds me of Gary Bernhardt's "The Birth & Death of JavaScript" talk[0], which one of the best comedy programming talks. Despite the comedy, it's also a half-decent idea.

[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#44

Post by silverwind »

gigel82 wrote: post #24
jluxenberg wrote: post #7

For what it's worth; `eslint-plugin-react` has been around for a long time and seems to support running in very old versions of Node.JS (back to v4[1] apparently! tho I can't find anything documenting that for sure.) I was surprised to learn that Object.values is only supported in Node >v7, Object.fronEntries was added in v12, etc. So for this project maybe the polyfills are needed. [1] https://github.com/jsx-eslint/…

Genuinely curious, are there people out there using newer versions of this package with old / unsupported versions of Node (in production)?

Not really. Adoption of new Node versions is quite quick, given their short support periods.

https://nodejs.org/metrics/summaries/version.png

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#45

Post by smallnamespace »

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 npm install will see much better adoption than one that requires each user to configure their babel/swc/etc. correctly, especially since the library can be a dependency of another library.

There's currently no standardized mechanism in the npm ecosystem to do the equivalent of "Install this library, and also configure your environment to pull in all required polyfills" so that the required functionality is available in global scope. One reason is because the transpilers that automatically polyfill into global scope are third-party tools.

Maybe a standard mechanism like this should exist, but it doesn't today, hence the quite reasonable choice of library authors to directly use polyfills because doing so:

1. Avoids pollute the global namespace by avoiding applying a polyfill globally

2. Works as a dependency without additional configuration by the user

3. Preserve backwards compatibility

A somewhat cheap fix to at least reduce duplication of polyfills would be for libraries that need polyfills to accept a wide version range. That would give the package manager room to pick a version that's compatible across call sites.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#46

Post by phire »

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.

It's hard to tell.

The author of both packages has since moved the github repos to an organisation named "i-voted-for-trump" and labelled the packages with the "troll-bait" tag.

But the author also claims those packages where created when they were learning to program, and they seem to have stuck with the idea of small libraries (just not quite that small). The changes seem to be due to grief the programming community has given him about those packages, as some of the worst examples of the pattern.

I suspect the author was being slightly satirical by choosing to do the simplest possible NPM library. But at the same time they probably believed it was a useful package, allowing new programmers (like himself) to calculate the evenness/oddness of numbers without needing to know or google the mod-2 trick. And if you are going to learn how to create npm packages, might as well start small.

If they were aiming to be slightly satirical, they were not expecting that level of outrage.

It's worth pointing out that the libraries do slightly more than just mod-2. It checks the argument passed in was actually an integer, and throws descriptive error messages if the argument is not a number or not an integer.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#47

Post by pphysch »

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.

Those may be satirical, but `leftpad` is real.

https://qz.com/646467/how-one-programmer-broke-the-internet-...

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#48

Post by tedunangst »

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?

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#49

Post by phire »

jluxenberg wrote: post #7

For what it's worth; `eslint-plugin-react` has been around for a long time and seems to support running in very old versions of Node.JS (back to v4[1] apparently! tho I can't find anything documenting that for sure.) I was surprised to learn that Object.values is only supported in Node >v7, Object.fronEntries was added in v12, etc. So for this project maybe the polyfills are needed. [1] https://github.com/jsx-eslint/…

There are two separate questions:

"Should libraries still be polyfilling to support ancient runtimes?" and "How should that polyfilling be implemented?"

Even if a library wants to maintain backwards compatibility, we can still argue this method of polyfilling (especially the phony polyfills) is damaging to the wider javascript ecosystem.

In an ideal world, the cost of polyfills for developers who don't need them should be zero.

For developers using bundlers, the bundler is expected to implement any required polyfills for the developer's targeted runtimes, and having the library ship with it's own polyfills is counterproductive at best. However, I suspect these libraries wish to maintain compatibility for developers not using bundlers.

Maybe npm should be upgraded to support multiple variants of packages? That way these libraries could ship both polyfilled and non-polyfilled versions of their packages in parallel.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#50

Post by phire »

gigel82 wrote: post #24
jluxenberg wrote: post #7

For what it's worth; `eslint-plugin-react` has been around for a long time and seems to support running in very old versions of Node.JS (back to v4[1] apparently! tho I can't find anything documenting that for sure.) I was surprised to learn that Object.values is only supported in Node >v7, Object.fronEntries was added in v12, etc. So for this project maybe the polyfills are needed. [1] https://github.com/jsx-eslint/…

Genuinely curious, are there people out there using newer versions of this package with old / unsupported versions of Node (in production)?

It probably happens, but not really on purpose.

If the package.lock file gets deleted or someone runs a global npm-update then npm will update any packages while respecting semantic versioning.

It's possible an organisation forgot to include the package.lock file in their deployment image and they get updated npm packages every time they redeploy. It's also possible a developer making minor changes to a legacy system triggers packages to be updated, perhaps without even noticing.

Post reply on HN