Hacker News new | past | comments | ask | show | jobs | submit | triblondon's comments login

Hi, I'm the original author of the polyfill service. I did not own the domain name nor the GitHub account. In recent years I have not been actively involved in the project, and I'm dismayed by what's happened here. Sites using the original polyfill.io should remove it right away and use one of the alternatives or just drop it entirely - in the modern era it really isn't needed anymore.


People should have never started including javascript from third-party domains in the first place. It was always playing with fire and there were plenty of people pointing out the risks.


I maintain the polyfill service. I'm very much aware of this issue, and we have tried to take steps to mitigate these concerns:

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.


Would you trust the FT and Fastly to have access to all local data all your desktop applications?

That's what you're building for the web. #1 doesn't absolve you of the culpability of promoting such a fundamentally flawed tool.


polyfills.io is not an FT service.

polyfill.io is the original service by Jonathan Neal that our service is based on. It is shortly to be decommissioned.

cdn.polyfill.io is our new service, the subject of this HN thread, and a collaboration between Jonathan Neal and the FT.

polyfills.io is an unaffiliated project by Jonathan Ong.

The naming is confusing. Hopefully it will be clearer when we're able to decommission the original polyfill.io, and I've asked Jonathan Ong to consider renaming his.


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


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.


Not Mozilla. The polyfill service is made and hosted by the Financial Times. Mozilla just kindly offered us a posting on the Hacks blog.


The polyfill service was created and is hosted by the Financial Times. Mozilla is not affiliated.

There are good reasons why you cannot make a good choice of polyfill prior to knowing the browser family and version, primarily due to polyfill variants (more details in the Hacks post).


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: