Add TextEncoder.prototype.encoding getter, fallback to property assigment for engines without getter support such as IE8

[JakeChampion]

Fixes https://github.com/anonyco/FastestSmallestTextEncoderDecoder/issues/12

[anonyco]

Sorry. I have been busy over the past few day, but I am looking forwards to a more open week where I can work on this.

• You are correct that TextEncoder.prototype.encoding is required per the specs, and your implementation of this property is spot-on specs-compliant. Excellent work.
• I love your dedication and enthusiasm. Thank you for being considerate enough to rebuild the project before submitting the PR. However,
• I don't want merge this pull request. FastestSmallestTextEncoder is designed to cut reasonable corners in order to reduce its size. You might see a condition checking the TextEncoder.prototype.encoding property in a compliance test suite, but no real production code is going to check this property.
• The purpose of TextEncoder.prototype.encoding was for future possible encodings support, but the specs have killed any hope of that happening in the future.

Because I respect your perseverance so much, I'm willing to create a 3rd flavour of this library which boasts complete specs compliance if you want me to. The reason why the main flavour will not recieve these fixes is because the fixes will likely double the file size, which is unacceptable to me. Otherwise, I am going to have to let this good pull request go. Thank you for the effort you have put into this.

Sincerely, Jack Giffin

[anonyco]

Additionally, this library does not support streaming and ignoreBOM, FYI.

[JakeChampion]

A fully spec compliant implementation would be amazing to see :-) we are looking to add TextEncoder and decoder polyfills to https://polyfill.io and were hoping to use an already written polyfill rather than authoring it by myself. I'm happy to help with testing across browsers and for spec compliance on any polyfills you write :-)

[anonyco]

I'll begin work on a fully specs compliant version. However, please let me say my two cents:

• I like the concept on polyfill.io, however
• I dislike the execution of this service and think it should offer an alternative version.

The reason for why is because

• In my mind, Polyfills should be decently performant and reasonably small. People using old browsers are already having a crummy experience browsing the web, so why make their experience even more miserable?

In my mind,

• A good polyfilling service should offer an alternative polyfill bundle that might not be 100% specs-compliant, but works perfectly in all real-world use cases.
• For example, Object.defineProperty might be required on TextEncoder for specs-compliance, but real-world code will never know the difference because no real-world code for-in iterates over a TextEncoder or tries to set read-only properties.

Thank you for hearing my two cents. I'll begin work on a new flavour of this polyfill.

[anonyco]

Not so fast. I have not been devoting as much time to this project as I should, but I am trying hard to find time for it, and am bound to find time eventually because things are looking to clear up in the next 3 weeks.