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

An easier way of using polyfills

hacks.mozilla.org

Post reply on HN
Print view View original

31–40 of 80 posts

Re: An easier way of using polyfills

#31

Post by ultimape »

teacup50 wrote: post #30

Something is very wrong with how web developers think about threat models if they're so incredibly willing to load completely arbitrary code into their customer's applications from a source that isn't even remotely party to the vendor/customer relationship.

This was actually a major security issue on some gov't websites point out a while back. Something about obama's blog's admin page using 3rd party google analytics...

I can understand something like cloudflare or other major vendor like google's cdn being more trustworthy, but even then there would need to be some sort of signature to verify the content (like they do on mega) before it could truely be trusted as not being compromised. That removes the speed benefits of a CDN since the preexisting file will need to be loaded and checked everytime.

Re: An easier way of using polyfills

#32

Post by RDeckard »

Havvy wrote: post #29
chc wrote: post #19

Earlier quoted context omitted.

I don't see what's stupid about that. Are you suggesting that anytime we want to talk about polyfills, we should instead write the following? #include "config.h" // ... #if !HAVE_FOOBAR void foobar(...) // missing: implement ourselves { } #endif Because that's nuts. This usage is actually more useful than the one that's a contraction of "polygon filling."

Well, there's "shim"....

What did the [deleted] parent comment say?

Re: An easier way of using polyfills

#33

Post by ben336 »

Groxx wrote: post #26

Hm. Alternatively, they could serve the same js to everyone, and (assuming sites use the CDN) it would be cached across pages, so users would only pay for it once. Zero fanciness needed on the CDN. How big is the "full" set of polyfills anyway? Probably small enough that a single download isn't an issue on even dialup? -- That aside, polyfill ALL the things. Hopefully making it easier makes it common, which lets devs…

> How big is the "full" set of polyfills anyway?

Google's polyfills for custom elements that they ship with Polymer weigh in at around ~151Kb of JavaScript, around 10x the size of a small library like Underscore, and 4-5x times the size of an MVC framework like Angular. And they only cover about 5-6 specs (the 4 webcomponent specs and a few more to support them) Those are admittedly hard to polyfill features that will be bigger than most, but it turns out that polyfilling "everything" is hard and would add significant page weight.

Re: An easier way of using polyfills

#36

Post by GuiA »

smlacy wrote: post #34

A brief introduction to "polyfilling" and what that means would be pertinent. I've never heard that term and have no idea what this is about, nor do I care.

As a graphics guy I thought they referred to the algorithms used to fill polygons, but it turns out that "polyfills" in web developer parlance are developer implementations of things that should be standard in the browser but aren't.

E.g. maybe all browsers implement an array sorting function, except for Internet Explorer. So for IE clients you'd load a "polyfill", which would be JS code that implements array sorting.

I'm really glad I'm not a JS developer.

Re: An easier way of using polyfills

#37

Post by ahoge »

Groxx wrote: post #26

Hm. Alternatively, they could serve the same js to everyone, and (assuming sites use the CDN) it would be cached across pages, so users would only pay for it once. Zero fanciness needed on the CDN. How big is the "full" set of polyfills anyway? Probably small enough that a single download isn't an issue on even dialup? -- That aside, polyfill ALL the things. Hopefully making it easier makes it common, which lets devs…

> How big is the "full" set of polyfills anyway?

Right now it's around 75 kB without minification and without gzip. However, this doesn't include any code for doing feature detection.

So, my somewhat educated guess would be: around 30 kB (which is comparable to jQuery).

Re: An easier way of using polyfills

#38

Post by ahoge »

saurik wrote: post #25

Does anyone know why is Array.from not able to be supported on the most recent versions of Firefox? (That's the one feature where the polyfill works on older browsers but apparently does not work on newer ones.)

Firefox 32+ supports it natively.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

http://kangax.github.io/compat-table/es6/

There doesn't seem to be anything wrong with Firefox 32+'s implementation.

Re: An easier way of using polyfills

#39

Post by coldtea »

smlacy wrote: post #34

A brief introduction to "polyfilling" and what that means would be pertinent. I've never heard that term and have no idea what this is about, nor do I care.

Well, if you never heard that term, and

1) you are a front-end JS developer, perhaps front-end JS development is not for you.

2) you aren't a front-end JS developer, then the post wasn't meant for you, so not much need to explain anything.

Re: An easier way of using polyfills

#40

Post by mistercow »

politician wrote: post #35

I love it. It'll be interesting to see if browser vendors will start attempting to detect these sorts of polyfill services and respond with their own browser-bundled or -specific polyfills.

Why would a browser want to bundle a polyfill, instead of just implementing the feature in question?
Post reply on HN