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

71–80 of 112 posts

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#71

Post by crummy »

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…

You know, it's heresy to say, but if there was some kind of analytics or reporting done by the plugin we could know for sure that no node v4 users are out there on it and upgrade the deps and be done with the whole argument.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#72

Post by MBCook »

e_y_ wrote: post #8

> Polyfills that don’t polyfill This is what's sometimes called a "ponyfill". The idea is to avoid messing with global scope (monkeypatching), which could be problematic if you have multiple polyfills for the same API or polyfills that don't perfectly match the native behavior. This can be a good thing in some situations, but in general it's probably best to leave polyfill decisions to the bundler so you can decide w…

I get not defining it yourself, especially if your polyfill is limited to the sliver of a feature you use, but why not check if the feature is there first?

Ok, maybe someone else monkeypatched it. But at least you’d end up using the native functionality if it was there.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#74

Post by Klonoar »

arbol wrote: post #40
Klonoar wrote: post #23

Earlier quoted context omitted.

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.

MooTools springs to mind

MooTools, Prototype, Dojo, YUI... what an era.

It sometimes feels like part of what we deal with now in the JS world is due to half the crowd not knowing what came before.

(Edit: to be clear, I think the other half is responsible for the advancements... so it probably evens out)

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#75

Post by Izkata »

Klonoar wrote: post #74
arbol wrote: post #40

Earlier quoted context omitted.

MooTools springs to mind

MooTools, Prototype, Dojo, YUI... what an era. It sometimes feels like part of what we deal with now in the JS world is due to half the crowd not knowing what came before. (Edit: to be clear, I think the other half is responsible for the advancements... so it probably evens out)

One of the systems I currently work on has all five of those. Which one was in use was developer's choice for pretty much any given page or feature.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#76

Post by samus »

forgotmypw17 wrote: post #60
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.

Since IE6 depends on the schannel implementation of the OS, it should not support neither TLS1.2 nor TLS 1.3. This means that it simply can't access the modern web anymore. Maybe there are still webservers out there though that still support outdated SSL/TLS versions and were never patched shudder

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#77

Post by bsimpson »

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

esm.sh kind of does this for livecoding environments (e.g. Codepen/Colab) where you're using instead of a bundler.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#78

Post by samus »

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…

Modifying global scope is the whole point of a polyfill though. And polyfills check themselves whether they were already applied or not.

Maybe a step to a more sane situation would be reducing redundancies between polyfill libraries to ensure they don't step on each other's toes.

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#79

Post by bsimpson »

mhagemeister wrote: post #17
e_y_ wrote: post #8

> Polyfills that don’t polyfill This is what's sometimes called a "ponyfill". The idea is to avoid messing with global scope (monkeypatching), which could be problematic if you have multiple polyfills for the same API or polyfills that don't perfectly match the native behavior. This can be a good thing in some situations, but in general it's probably best to leave polyfill decisions to the bundler so you can decide w…

Author here. Good point. Agree that the ideal scenario would be that the end user (or the tools they use) have the final say in which polyfills to load. It's a bit of a bummer that they are shipped as part of npm packages without an easy way to get rid of them. I wonder if our industry will move to publishing the original source files to npm in the long run. Only the last piece of the chain, the developer using these…

I've always been kind of surprised that original sources aren't part of the NPM culture. For a long time, I included "typescript:main" in my package.jsons and configured my tools to prefer that to "main" (and now "module").

Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue

#80

Post by samus »

onli wrote: post #64
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…

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

And one could download stripped-down versions with just the features needed. Important especially with jQuery UI since it had quite some heavy components.
Post reply on HN