JavaScriptを書くにあたって、未だにブラウザによっては存在しない機能を考慮せざるを得ない状況が続いています。そこで取る対策として、PolyfillとPonyfillがあります。
気の抜けない、ブラウザごとの差
最近でこそブラウザは強制バージョンアップするものが増えてきましたが、もはやバージョンアップすることのないIE 11、そしてOSとセットでしかアップデートできないiOSのSafariなど、常に最新といかない環境も残り続けています。さらに言えば、JavaScript自体もECMA 201xというように、毎年バージョンアップし続けるので、ブラウザごとにそれをキャッチアップできるタイミングも違ってきます。
ということで、どこまで行っても「ブラウザごとの実装差」は残り続けることとなってしまいます。
Polyfillのメリットと欠点
Polyfillとは、「標準となったメソッドが存在しない場合に、自分で供給してしまう方法」です。JavaScriptに加わる新機能の中で、文法ごと書き換わってしまうものはどうしようもないですが、新しい標準関数が増えた場合は、自分でprototypeに書き足してしまうことも可能です。
なお、「Polyfill」という単語は、壁などの「隙間を埋める」ペーストのPolyfillaに由来しているとのことです。
Polyfillのメリットとしては、「本体コードを書き換えずに済む」ということがあります。足りない関数だけPolyfillを入れれば、残りのコードはそのままで、幅広いブラウザに対応できます。
ただし、Polyfillのデメリットとしては、いくつかあります。今までできたことをスッキリ書くような、ユーティリティ型のメソッドであれば、今ある機能で、仕様と全く違わぬ動きをさせることができます。一方で、新しく加わったものの場合、完璧にPolyfillできないこともあります。例えば、WeakMapの「キーがガベージコレクトされたら値も巻き添えになる」という動作は、JavaScript内で実現することができません。
そのように、「正式なメソッドと微妙に異なるPolyfill」は、他のライブラリと組み合わせた際に、思わぬバグのもととなります。
Ponyfillという概念
そこで、「Polyfill」という単語を少し書き換えた「Ponyfill」という概念が登場します。これは、「Polyfillが暴れん坊なのに対して、ポニーのようにピュアな」もの、を意図しているとのことです。
実装自体はPolyfillと同様に自前のJavaScriptを用意はするのですが、それを標準オブジェクトに上書きするのではなく、全く別個の関数として使えるような形で用意しておく、というような手法です。
残酷な現実
で、実際のPolyfillライブラリを見ていると、存在しないブラウザにコードを追加するコードどころか、「既存の実装のバグをチェックして、バグが存在する場合には自前コードに切り替える」ものすら存在していて、なんだか闇に片足を突っ込んだような気分になることもあります。