An easier way of using polyfills

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.

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

Do a significant percentage of users spoof their agent?

I'm more worried about supporting older users on old machines who barely know the difference between Internet Explorer and the internet than in supporting someone who knows exactly what a UA is and how to spoof it.

If a lot of the pages you view end up broken, you would just change the way you lie about your user agent so that it's more prominent to you so you don't forget.

Your complaint is like complaining that if you set your browser's "language preference"* to only contain Dutch, you will end up getting served pages in Dutch.

Why is that different? You ask for Dutch only because supposedly you can understand it, and you ask for a presentation against a particular browser/version because supposedly you're rendering in it. Seems fine to me!

Otherwise, we might as well only serve pages in Esperanto - you know, the universal language standard.

* "(or, more appropriately, that of its user) along with every HTTP request being made in the form of the Accept-Language header that is part of the HTTP/1.1 RFC"

Yeah, properly serving that 0.01% demographic would be hard...

/s

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.

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?

One of the reasons that I'm such a big fan of Chrome's End-to-End project[0] is that it looks like it may provide a good way to bring real security to modern rich applications. In the current incantation it's not going to be suitable for use in every site out there, but it appears to be a really solid step in the right direction.

[0]: https://code.google.com/p/end-to-end/

1. You can easily run the service yourself, just download it from the github repo

2. The hosted version is hosted by the FT and sponsored by Fastly, so you're not importing code from some random unknown entity. Those corporations practice good security awareness (in the FT's case it dramatically improved about 2 years ago), but if you don't believe us, see point 1.

No, the implementations had bugs because they had bugs.

The bugs were not documented or fixed due to lack of tests or use.

For some this is a distinction without difference; For some, there is a huge difference.

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.

No. What Mozilla did was explain their reasons for doing so. So at the very least your comment should engage with their stated reasons in some detail. Otherwise it's hard for the rest of us to know whether you've got a valid objection or you just replied without really reading the original article.

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

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

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.

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.

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.

However, older browsers like IE <9 do not support ES 5, so if, as a developer, you try to call .map on an array in IE 8, you'd get an error.

A polyfill uses Javascript's awesome ability to add functions to basic types, and extend the language in other ways. So if a browser does not ship with, for example, array.map() itself, a polyfill can do array.map = function() {} and implement it.

That way, a developer can simply use array.map and not have to do a different implementation (fall back on a ye olde for-loop).