Polyfilling, when is it too much?
I’ve summed up this question into one sentance.
Is it practical to polyfill all of the IE8 deficiencies with one solid javascript file, as in, would there be any drawbacks (performance) or blockages (impossibility to polyfill some features)?
Question Deprecation: (history)
I’ve been working with my company for about half a year now, and we’ve constantly been fighting with clients on upgrading their browsers. Everyone is of the mind that moving to a newer browser is only going to introduce more problems than solutions (they have internal, old web applications designed for in-house work)
I’m at the point where I’ve had to hunt down and polyfill so many things with IE8 that I’m wondering if there is any draw-back to polyfilling every deficiency that IE8 has (or at least making it so that the javascript doesn’t error/fail)
Is it unreasonable to expect to be able to polyfill all of the deficiencies in older outdated browsers such as IE6-IE8, or would that be a bad idea (performance? stability?)…
If this is a possibility, how come there are no full-feature polyfill libraries, everyone will point to “modernizr”, that is FEATURE DETECTION, and offers no polyfills of it’s own.
So, wheres the IE8 master/full polyfill library hiding, or am I gonna have to slave over this?
Edit: the reason why I’m not just picking out the parts I need, is because there might be deficiencies we are not aware of, I’d love to have a fix-all for Internet Explorer, so if this doesn’t exist I’m going to make it myself.*
4
Is it practical to polyfill all of the IE8 deficiencies with one solid
javascript file …?
Not really, No. As an example, start with <canvas>. There are several “polyfills” available, but most farm out the work to a browser plugin like Flash or Silverlight. This is a decidedly different approach than simply monkey patching the JavaScript Array prototype to add an indexOf function. A faux canvas depends on third party software. That may be better than nothing, but it’s certainly not bullet-proof. It probably doesn’t make sense to include it in a master IE8 polyfill since everyone’s goals and technical restrictions vary.
SVG polyfills share the same problem. Some target VML, others <canvas>, and at least one targets Flash. HTML5 audio and video polyfills fall back to Flash. Geolocation and Web Sockets polyfills employ very different mechanisms than the native API. They might work great for you. Then again, they might not.
You may have better luck with ECMAScript shims, but even there you may run into issues. As an example, take a look at the “may fail” API of the es5-shim. It’s just not possible to guarantee perfect behavior without native support.
In the end, it’s best for everyone to pick and choose what they’ll use and when. It’s a pain, but your users and support staff will thank you for it.
Depending on what you are doing performance can be a big issue. Polyfills can fix many programming / api issues but you can’t make the old javascript engine anywhere near as performant as modern browsers. Things like filtering large lists client side will cause noticeable lag on IE but will work fine on modern browsers for example.