なぜ多くの開発者は「プラットフォームを使わない」のか？

長年、ウェブ標準、パフォーマンス、アクセシビリティの提唱者は、ウェブ開発者に「プラットフォームを使え」と訴えてきました。私もその一人でした。その主張は単純です。ブラウザが提供してくれるのに、なぜ自分でJavaScriptで何かを構築する必要があるのでしょうか？あなたが構築するものは何であれ、ブラウザが標準で提供してくれるものよりもパフォーマンスが悪く、ユーザビリティも劣る可能性が高いでしょう。 しかし、少なくとも「プラットフォーム懐疑派」の開発者がどこから来ているのかを理解するために、あえて反対の立場を取る価値があると思います。「プラットフォームを使え」がそれほど明白なら、なぜ多くの人が説得される必要があるように見えるのでしょうか？ 最も明白な理由は歴史的なものです。長い間、ブラウザはそれの上に構築されたエコシステムに追いつこうとしていました。jQueryのようなライブラリは、ブラウザが同等のAPIを実装する間に、重要なギャップを埋めていました。そして、それらを使えるようになるまで、IE6のような遅延ブラウザが淘汰されるのを待たなければならないこともありました。今日、ほとんどのブラウザはエバーグリーン（Safariは議論の余地がありますが、年間約7回というのも悪くはありません）ですが、2020年代初頭までは、ウェブ開発者は明らかに凸凹なウェブに対処しなければなりませんでした。その環境では、自分で構築するのが賢明な選択でした。 もう一つの理由は慣れです。npmでReactコンポーネントを探すことに慣れていると、問題に関わらず、それに手を伸ばしがちです。「スティッキーポジショニング」をnpmで検索しても、「おい、CSSのposition: stickyを使えよ」というパッケージはありません。そして多くの場合、堅牢な標準が存在しても、npmのライブラリはフレームワークのエルゴノミクスと、その下のプラットフォームとの間に有用なギャップを埋めていました。 私は、多くのReact開発者がJSXとReactのイディオムに固執し、生のDOM APIを「気持ち悪い」と感じる一方で、生のDOM操作が一般的な低レベルライブラリを喜んで使うという事実が興味深いと感じていました。例えば、仮想リストライブラリは純粋なパフォーマンスのために生のDOM APIを喜んで使うかもしれませんが、初心者React開発者がより理解しやすい高レベルのプリミティブを公開します。ある意味、Reactコンポーネントのエコシステムは、より専門知識のある人が、馴染みのないプラットフォームAPIをより馴染みのあるフォームファクタにパッケージ化するという自然な分業につながりました。 この効果の一部は、ドキュメンテーションによっても推進されていました。多くのnpmパッケージには、愛情深く詳細なREADMEや、例、チュートリアル、スクリーンショットを備えたウェブサイトがあります。一方、MDNがウェブドキュメントの定番の場所（Googleのより将来志向の部門であるweb.devとともに）として確立されるまで、ウェブプラットフォームのドキュメントはブログ、StackOverflow、CSS Tricksのようなサイトに散在していました。そして、これらのサイトの多くは、jQueryやGreenSockのような有名なライブラリを使うように指示していました！DragulaのサイトとMDNのドラッグアンドドロップのページを比較してみてください。おそらく前者のほうが今でも魅力的です。 しかし、サードパーティライブラリとプラットフォームAPIだけの問題であれば、「プラットフォームを使え」という反感は完全に説明できないと思います。怠惰な開発者（あるいは私が繰り返しているだけでしょうか？）で、直面しているどんな問題にも既製のソリューションを求めているだけなら、そのソリューションがnpmから来るのか、ブラウザから来るのか、それとも誰かのランダムなGitHub Gistからコピーされるのかを気にする可能性は低いです。彼らは問題を解決して次に進みたいのです。 しかし、「プラットフォームを使え」という考えに対する、私が探求したい別の源泉があります。ある種の開発者にとって、自分で何かを構築することは単に楽しいのです。そして、しばしば結果として得られるコードは、特にウェブプラットフォームに関する百科事典的な知識を持っていない場合、より推論しやすくなります。そして、一度何かを構築すると、自分の手作りのコードを維持し、いじくり回したくなるような、いわゆるIKEA効果が生じることがあります。 例として、モーダルダイアログを構築しようとしていると想像してみてください。これらのダイアログがどのように機能するべきかを視覚的に理解しているかもしれません。コンテンツが画面に表示されますが、背景はまだ見えており、部分的に隠されています。そして、ダイアログの外側をクリックすると閉じられるかもしれません。そこで、position: absoluteとz-indexを使ってダイアログを正しく配置しようとするかもしれません。しかし、背景はスクロールしてしまうので、bodyのoverflowを無効にする必要があります…。そして、アクセシビリティについて理解しているなら、Escキーで閉じる処理、フォーカストラップの構築、ダイアログを起動した要素にフォーカスを戻す必要があることに気づくでしょう…。 多くの開発者にとって、私が説明したことは悪夢のように聞こえるかもしれません（そして、半ばしか機能しないものを作る良い方法です）。しかし、多くの開発者にとっては、それは楽しいことに聞こえます！このものを構築し始めると、どれだけ学ぶことができるかを考えてみてください。そして、アニメーション、テーマ、オプションの「閉じる」ボタンを追加することで、独自のひねりを加える方法を考えてみてください…。気づけば、すぐに使えるライブラリを構築しています。それは、単に<dialog>を取得して一日を終えるよりもずっと楽しいです。なんてつまらないのでしょう！そして、私たちの多くにとって、<dialog>のようなAPIが存在する前は、これがウェブプラットフォームを学んだ方法でした！ 今「プラットフォームを使え」と提唱している多くの人々は、かつてポリフィル、シム、ライブラリの作者自身でした。私もそうなので知っています！私はPouchDBでの仕事の一環として、IndexedDB、WebSQL、その他のブラウザストレージAPIのツールの開発に何年も費やしました。それは最終的に、W3Cの標準会議に出席し、IndexedDB仕様自体に問題提起やプルリクエストを開くのに十分な自信を感じるようになりました。プラットフォームに埋めるべきギャップという強制力がなければ、そのレベルの専門知識を見つける興味や動機があったかどうかはわかりません。 もちろん、自分でやるのが常に純粋な善であるとは限りません。時にはそれは単なる無知から来ることもあります。特にウェブプラットフォームでは、CSSでより良く解決できる問題に対して、多くのJavaScriptソリューションが乱発された理由の一つは、多くの開発者がCSSの仕組みを深く理解する時間を取らなかったことだと思います。そして公平に言えば、CSSは歴史的に理解するのが難しかったです！サイトが「CSS Tricks」と呼ばれるのには理由があります。clear fix、float、min-width: 0のトリックなどは、直感的とはほど遠いです。CSSの内部アルゴリズムを理解しようとするよりも、欲しい命令的なロジックを想像して、それをJavaScriptで表現する方がはるかに簡単であることがよくあります。さらに、長年CSSには、行のクランプ、textareaのリサイズ、スクロールバーの非表示などの一般的なパターンを表現する簡単な方法がありませんでした。だからもちろん、開発者はすでに理解しているツールを使って自分で構築しました。 この「プラットフォームを避ける」という現象は、ウェブに限ったことではないと思います。それは、理解していないプラットフォームの上に構築しているどの開発者にも当てはまる可能性があります。例えば、私の職場では、様々な分析データを保存するためにClickHouseを使用しています。ある時、同僚と大きなJSONデータをカラムにどのように保存するかについて意見が分かれました。彼は保存前に圧縮するシステムを構築しましたが、私はデータを別のキーバリューストアに入れ、キーだけをClickHouseに挿入しました。結果的に、私たちは両方とも間違っていました！ClickHouseは自動的にデータを圧縮し、カラム型データストアとして、ClickHouseに任せる方が実際には行全体でより良い圧縮が得られます。そして、別のキーバリューストアは、カラム型SELECTがすでにやっていることの貧弱なバージョンに過ぎませんでした。これらのことに気づいたのは、ClickHouseのドキュメントを徹底的に読む時間を取ってから、仮説を証明するためのベンチマークを書いた後でした。最終的に、プラットフォーム自体が標準で提供できるものよりも遅くてぎこちないものを作ってしまったことにショックを受けました。 JavaScriptとウェブプラットフォームとの類似性は無視できませんでした。iOSやAndroidの開発者、ゲームエンジン上に構築している人、あるいはあらゆる種類のプラットフォームレイヤー上に構築している開発者であれば、おそらく同様の話を持っていることでしょう。 grizzled senior engineer（経験豊富なシニアエンジニア）のステレオタイプが、ジュニアの複雑で絡み合ったコードの山を取り除き、それを置き換えることができる人物であるのには理由があります。