On 07/23/2012 08:45 PM, John Spackman wrote: >> I have to disagree. The point of a Polyfill is to provide a native API >> if the client doesn't support it. This means using feature detection to >> determine if the Polyfill is needed and, if so, providing a fully >> standards-compliant implementation. Any library that fails to do either >> or both is outdated or plain buggy. > > Polyfills are great where you can choose to load a piece of code to fix > problem and where you know that's going to be the only piece of code > trying to fix that problem. If another polyfil is already in place, the > feature detection can fail. > How could the detection fail if the Polyfill works as it should? I'd love to see any examples of this so I can double-check my own feature detection code.
>> I know that in the real world things aren't perfect and sometimes you >> have to stick with an old library because it's no longer being >> maintained and/or you can't justify the effort to replace it, but still >> I don't think that we should drop the Polyfill approach just on the off >> chance that someone somewhere uses shaky code. > > I think the real world is exactly the point - it obviously isn't perfect > or otherwise we wouldn't have to consider polyfills in the first place and > what concerns me is that when a polyfil causes a conflict it could be > really hard to figure out what's gone wrong, especially where for example > script load order is determined at runtime. > Definitely a good point. I just think it's very unlikely since hey, it's 2012 and every JS library developer should know how to correctly implement a Polyfill. Maybe I'm just too optimistic ;) > The problem with polyfills for fundamental types like Array and Function > is that they are used by /every/ library, and therefore making a polyfil > could impact everything you use. > >> In fact, interoperability is a big argument in favor of Polyfills: Why >> should I have to look up what Array.forEach is called for every library >> I use? I'd much rather just use the native syntax and be done with it. > > But if you use another library don't you need to know if they provide a > polyfil anyway? And how many method names are we talking about here? Is > it really that much effort to type "qx.data.Array.forEach(myVar" vs > "myVar.forEach", when just /one/ side effect could cause a whole day of > debugging? > It's not about the typing effort, it's more about having to search through the API docs again every time I come back to a project after a few weeks. IMO the value of having a common language standard to code against greatly outweighs the risk. Regards, Daniel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
