
An easier way of using polyfills - rnyman
https://hacks.mozilla.org/2014/11/an-easier-way-of-using-polyfills/
======
Groxx
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 use a nicer version of Javascript.

~~~
ahoge
> _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).

~~~
Groxx
A definitely-flawed sorta-concatenation of all `if(detect.js){polyfill.js}`
files, plus some cleanup, plus syntax fixes, run through [http://closure-
compiler.appspot.com/home](http://closure-compiler.appspot.com/home) gives me
just under 10kb gzipped, just over 31kb raw.

Nice guess :) that seems not too bad, tbh.

------
AnkhMorporkian
While a neat idea in theory, I have some qualms about this. User agent
detection sounds great, until you have a user that spoofs their agent. I often
do so for various reasons, and from time to time I forget to turn it off after
I've finished what I was doing.

If this service becomes common, then I will be given broken webpages seemingly
at random. The other option, a polyfill covering specific features and served
to all clients, regardless of user agent, doesn't suffer from that.

~~~
nawitus
Most JavaScript polyfills first check if the native implementation exists, and
only if it doesn't the polyfill is activated. This shouldn't break anything.
However, the blog article states they use User-Agent detection over feature
detection. I hope they combine these solutions.

~~~
ben336
You can't use feature detection with a simple script tag. It's calling in a
script and the cdn chooses the file to send based on the user-agent. No
Javascript is run that would allow it to feature detect before choosing to
send the load. There may be feature detection afterwards of course.

~~~
coldnebo
I think we're saying that most modern polyfills do a feature check before
installing the polyfill... thus if you use Chrome with an IE agent, the
polyfill still checks before implementing -- it's just a little slower than
not installing the polyfill to begin with. Anyway, given the percentage of
people who do this, UA detection seems like an acceptable tradeoff.

~~~
ben336
Agreed, feature detecting afterwards makes sense. Others seem to be suggesting
feature detecting before requesting the polyfill script.

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

~~~
e12e
> Something is very wrong with how web developers think about threat models

Yes.

We have pretty much the same problem with the web, as we had with macro-
viruses an office suites -- because we're solving the same problems in the
same way, without learning from past mistakes. It might actually be worse,
because if you tell people you don't run macros in untrusted office documents,
most people will applaud you for being wise -- while if you say you use
noscript people will dismiss you as a paranoid Luddite.

Runable code created by random people, from random sources, in one address
space with access to all your user data -- what could go wrong?

~~~
coldtea
> _It might actually be worse, because if you tell people you don 't run
> macros in untrusted office documents, most people will applaud you for being
> wise -- while if you say you use noscript people will dismiss you as a
> paranoid Luddite._

Maybe because macros are a BS add-on functionality that does nothing for 99.9%
of Office users, whereas JS is a key component of the modern, dynamic, web.

> _Runable code created by random people, from random sources, in one address
> space with access to all your user data -- what could go wrong?_

Yeah, it's not like we have a security model for JS, sandboxed environments,
and even each tab running as a separate process.

~~~
teacup50
> Yeah, it's not like we have a security model for JS, sandboxed environments,
> and even each tab running as a separate process.

Sandboxed environments containing user data that web developers voluntarily
compromise by then inserting 3rd-party controlled code.

~~~
e12e
Precisely. I'm glad my comment didn't pass over everyone's head.

A little disappointed that it's teacup50 that pours cold water on coldtea, and
not the other way around. If only I had a biscuit-themed nick, to go with this
little sub-thread.

------
jongleberry
working on an alternative that doesn't use its own polyfills and instead uses
other people's well written libraries. i used polyfill.io before and half the
implementations had bugs due to the lack of tests. feedback welcomed!

[http://polyfills.io](http://polyfills.io)

~~~
triblondon
I maintain the polyfill service. I think it's great that more people care
about polyfilling older browsers and it would be so much more powerful if we
collaborated on one service. Your feedback on polyfill.io is accurate, but out
of date. I know you were very active in working with Jonathan on his original
service, and I'd be delighted to talk to you about how we can work together.

I'd also make a few points of feedback on your solution:

1\. It's confusing to name your service with a name that is only one character
different than ours. Some might interpret that the confusion is your
intention, which I'm sure it isn't - would you consider renaming it? We've
already seen confusion happen around polyfill.io (which is still the old
service for compatibility reasons) and cdn.polyfill.io.

2\. Granted, Jonathan's original polyfill.io had no tests. But that's one of
the things we've spent a lot of time fixing, and our test framework is now
extremely good. You're testing using naive feature-detects, while we have
relatively comprehensive test suites for many features and are adding more all
the time.

3\. Your targeting of browsers is based on data gathered from crowdsourced
sources like caniuse and MDN, whereas we establish compatibility through
testing our polyfills in every browser using an automated CI-driven process on
Sauce Labs.

4\. We are now starting to incorporate other people's polyfills where they are
better than ours, and have a mechanism to do that, and to store and serve the
appropriate attribution and licence information. We've actually considered
many of the polyfills that you have made part of your service.

5\. We've had discussions with several of the authors of the popular polyfills
you've included, and their main concern over the way we were considering
including their code was that we copied it into our repo rather than linking
their repo as a dependency. You're doing that too, and including more third-
party code than we have so far. It's totally legit within the licences they've
granted and it's a policy we'll probably continue to follow too, but we're
still thinking on how we can do this in a way that keeps everyone happy. For
the moment, this is encouraging us to lean more towards using our own code.

------
bshimmin
So we've spent years shouting out the mantra "test for features, not
browsers!" and now Mozilla, of all people, tell us that that was basically a
bit impractical, and we should just go back to user-agent sniffing like we did
8-10 years ago?

~~~
conradk
It looks like Mozilla is testing for virtually any web browser that is in use.
That seems OK.

And, you can choose to do feature detection if you wish. Here's a quick
example:

[https://cdn.polyfill.io/v1/polyfill.js?features=Array.protot...](https://cdn.polyfill.io/v1/polyfill.js?features=Array.prototype.every|always|gated)

More information about that can be found here:
[https://cdn.polyfill.io/v1/docs/api](https://cdn.polyfill.io/v1/docs/api)

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

~~~
ahoge
Firefox 32+ supports it natively.

[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Array/from)

[http://kangax.github.io/compat-table/es6/](http://kangax.github.io/compat-
table/es6/)

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

~~~
saurik
Thank you; the chart indicates it is not supported natively. There is a
feature on the site involving unit tests of each of the features: maybe
something about that unit test isn't working on Firefox 32? (Or maybe it is
just a mistake, of course.)

~~~
triblondon
Mozilla's implementation is the problem here, not the polyfill. The polyfill
is actually (on this point) a better implementation of the spec than the one
that landed in FF 32. What has happened here is that our test runner has
loaded the polyfill, but it has not installed because FF passes a naive
feature-detect. However, it goes on to fail the full test suite, so we
conclude that the polyfill does not work (which is strictly true) and mark it
accordingly on our compatibility chart.

Moz bug filed:
[https://bugzilla.mozilla.org/show_bug.cgi?id=924058](https://bugzilla.mozilla.org/show_bug.cgi?id=924058)

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

~~~
mistercow
Why would a browser want to bundle a polyfill, instead of just implementing
the feature in question?

~~~
politician
If browser vendors adopted this this opt-in, polyfill-first approach it would
make it _significantly_ less expensive and much simpler to progressively
rollout experimental features to the public.

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

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

~~~
elnate
3) you were born knowing everything about your trade, so no point posting
articles like these.

~~~
coldtea
I was answering to a parent who seems to have deleted his comment.

I'm not suggesting that everybody should know everything about their trade.
Polyfill on the other hand is an extremely common thing in the trade. You'd
expect a surgeon to know what a scalpel is.

Plus, he put it like: "I don't know what it is and I don't care". How about
bothering to Google the names you don't know, instead of demanding everybody
else to include introductory terminology lessons in their posts?

