IE First を避ける
by mizchi created at 2020/06/21/01:07
まず、去年の実績として、IE のシェアが 9% から 5% になっています。
Browser Market Share Japan | StatCounter Global Stats
世界だと 1.4% です。これは途上国などでは Android Chrome が支配的だからです。 https://gs.statcounter.com/browser-market-share/all
国内で「IE シェア」などでググって出るサイトは 9% と出ていますが、これはデスクトップのみの数字で、モバイルを含めた数字は 5%前後です。日本はさらに Chrome ベースの新 MS Edge の正式リリースがコロナと確定申告の影響で延期されており、リリースのタイミングでさらに減ることが予想されます。
去年の実績値でいえば、来年度には 2% 台、再来年には 1%を切っている可能性があります。これは toC なら十分にサポートを外すことを検討できる数値です。フロントエンドでは、シェア 0.5%を切った段階で完全にサポートしないことを検討していいと言われています。
主流なデスクトップブラウザが 2~6 ヶ月毎のローリングアップデートを採用していること、モバイル端末はそもそもの買い替えのライフサイクルが短いことから、今後は IE のような十年単位で残るレガシーは出現しづらい環境になりつつあります。
IE サポートをやめるわけではない
自分が主張したいのは、即座に IE のサポートをやめろ、という話ではありません。
新規に開発するソフトウェアの機能制約や開発体験で、IE の制約を取り払うことで生まれるメリットを考え、それが勝るならば IE をベースラインにせず、サポートを限定的なものにすることを検討する、という話です。
長きにわたる IE8,11 のシェアによって、フロントエンドエンジニアは、無意識に IE が可能なことがウェブの限界だ、と無意識に刷り込まれてしまっています。これだと、PWA や新しい発想を受け入れるのに時間が掛かります。例えば、ちょっと前には最新だともてはやされた ES2015 は、今ではビルドターゲットになりえます。
IE の範囲内では機能要件をサポートし、非機能要件、Polyfill の使用水準や、アニメーションの簡略化や CSS の装飾を簡素なモノにする、といった選択肢を、それが可能ならば優先的に選択する、という話です。そして、そのために IE が犠牲になることは、プロジェクトマネージャ等に最初に合意を取っておく必要があります。
界隈に詳しくない人向けに、なぜ、ここまで IE を問題にするか説明すると、IE11 は 6 年間ほど時が止まっており、そこから Chrome Firefox Safari の競争で激しく進化した他のモダンブラウザと歩調を合わせることが困難になりつつあります。JS はツールの発達でそれほどではありませんが、とくに CSS の開発の工数が嵩みます。それは、場合によってはもう一つ同じものをつくるような工数です。
発展的な未来のために
Safari はやや遅いといえど、基本的にモダンブラウザの足並みは揃っている現状です。(Chrome だけ独自機能が増えています)
webpack などの OSS のエコシステムは IE11 はまだサポートされていますが、徐々に IE をサポートから外す動きがあります。
また、 Snowpack や vitejs/vite: Native-ESM powered web dev build tool. It's fast. のような、IE を切ることでモダンブラウザの機能をふんだんに使う方向性のツールが出現し始めています。
JS 周りでは Service Worker, ESM の dynamic import の活用、CSS では display: grid が大きいと思っています。
というわけで、IE をメインラインに据えず、機能要件だけに落としていくことを提案します。
追記: 具体的な方針
まずモダンブラウザ向けに作って、その上で IE 用に別ビルドを提供する、といった方法で、モダンブラウザビルドから負債を切り離していくことを自分は推奨しています。それが実行環境/開発環境のパフォーマンスに大きく寄与します。
リリースされたものは nomodule や IE だけ polyfill.io 通すといったことが可能でしょう。
import/export の ESM を素で使うのはネットワーク RTT を挟むパフォーマンス上の問題があり、SPA でバンドル処理がなくなることは考えにくいです。依存の深さで 回数遅延 xRTT のレイテンシが追加されるからです。
とはいえ、今後は webpack 一強を脅かすツールが出現することが予想されます。それを受けて webpack 自体も大きな変化を遂げると予想されます。
フロントエンドでは採用したツールチェインがエコシステムの本体であり、採用するツールチェインの選択がアプリケーションの品質を大きく左右することがあります。
追記: toB での MS Edge について
今年 1 月にサポートの切れた Windows 7 にも 新 MS Edge は配布されています。これは、古い端末でも(最新アップデートを受け取っている必要はありますが) Chromium ベースの Edge が使えて、バックグラウンドでローリングアップデートされるということです。
これはつまり、古いマシンでも最新 Chromium が起動することが保証されているので、IE のサポートを打ち切って、代わりに Edge での起動を促す画面を出す、みたいな方法が現実的になります。むしろ toB の方が枠組みさえ作れば IE サポートを打ち切りやすい環境があると思っています。