61–70 of 80 posts
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.
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.
However, older browsers like IE 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).
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.
Earlier quoted context omitted.
Well, there's "shim"....
What did the [deleted] parent comment say?
Basically, it sounded like the comment author went in expecting an article about rasterization and was upset to find that web developers used the word for something else. Which I'll admit I've also done before on other topics, but you can't begrudge other fields their jargon.
[deleted]
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."
Actually, it's a reference to polyester fiberfill (poly-fil), a material used for upholstery, crafts, etc.
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).
Nice guess :) that seems not too bad, tbh.
Earlier quoted context omitted.
Polyfills won't break your page and random, worse case you get worse performance over native. However the point of a polyfill is to do exactly what the native method would have done if it existed
Yes but the way mozilla has chosen to implement this is to send the code over the wire based on the clients UA. So if a method doesn't exist that should exist the client will never receive it. It would be cool if they allowed you to disable this feature, and just use feature detection and always load the code for the requested item.
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).
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?
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
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.