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

71–80 of 80 posts

Re: An easier way of using polyfills

#71

Post by triblondon »

saurik wrote: post #52
ahoge wrote: post #38

Earlier quoted context omitted.

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.

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

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

Re: An easier way of using polyfills

#72

Post by triblondon »

dmbass wrote: post #21
[deleted] wrote: post #20

[deleted]

This post is about the FT service http://polyfills.io/

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.

Re: An easier way of using polyfills

#73

Post by coldtea »

BrandonM wrote: post #63
coldtea wrote: post #39

Earlier quoted context omitted.

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.

It's not very productive to talk down to people, even if it's satisfying to you. There's a better way: http://xkcd.com/1053/

Talking down? I was replying to the parent's "I don't know what this is and I DON'T CARE" comment.

If you don't care, you can always not comment.

If you do care, Google is a keyboard shortcut away, and it's up to you to get informed, not to harass the post autors about not including a terminology section.

How about "I don't know what side-effects are and I don't care" posted for every Haskell post? Or "I don't know what functions are"? Where does this BS ends?

Re: An easier way of using polyfills

#74

Post by coldtea »

e12e wrote: post #48
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.

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

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

Re: An easier way of using polyfills

#75

Post by triblondon »

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.

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.

Re: An easier way of using polyfills

#76

Post by BrandonM »

coldtea wrote: post #73
BrandonM wrote: post #63

Earlier quoted context omitted.

It's not very productive to talk down to people, even if it's satisfying to you. There's a better way: http://xkcd.com/1053/

Talking down? I was replying to the parent's "I don't know what this is and I DON'T CARE" comment. If you don't care, you can always not comment. If you do care, Google is a keyboard shortcut away, and it's up to you to get informed, not to harass the post autors about not including a terminology section. How about "I don't know what side-effects are and I don't care" posted for every Haskell post? Or "I don't know w…

Sorry, I just recoil against phrases like "x is not for you."

You seem to view this individual commenter as a sea of uncaring people, but it's just one person. Change their mind, and their contribution to the "BS" does end.

Even if a response like yours seems deserved, it's not very productive. It certainly doesn't help someone to care more.

Re: An easier way of using polyfills

#77

Post by teacup50 »

coldtea wrote: post #74
e12e wrote: post #48

Earlier quoted context omitted.

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

> 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 ra…

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

Re: An easier way of using polyfills

#78

Post by teacup50 »

triblondon wrote: post #75
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.

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 dramatic…

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.

Re: An easier way of using polyfills

#79

Post by e12e »

teacup50 wrote: post #77
coldtea wrote: post #74

Earlier quoted context omitted.

> 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 ra…

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

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.

Re: An easier way of using polyfills

#80

Post by politician »

mistercow wrote: post #40
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?

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.
Post reply on HN