何年にもわたり、ウェブ標準、パフォーマンス、アクセシビリティの提唱者たちは、ウェブ開発者に『プラットフォームを使う』ように促してきた — つまり、カスタムソリューションを構築したりライブラリに頼るのではなく、組み込みブラウザ機能に依存するという意味だ。議論は単純明快だ：なぜ自分でJavaScriptで何かを構築する必要があるのか、ブラウザが同等の機能をオフ・ザ・ボックスで提供し、さらにパフォーマンスと使いやすさが優れているのに。しかし多くの開発者はこの助言に抵抗しているように見える。なぜそうなるのかを理解するには、表面的な説明を超えて見る必要がある。歴史的要因が大きな役割を果たしている。ウェブの歴史の大半において、ブラウザは開発者のニーズに遅れをとり、開発者はjQueryなどのライブラリでギャップを埋めざるを得なかった。標準化されたAPIを安全に採用できるようになるまで、開発者はIE6などの古いブラウザが姿を消すのを待たなければならなかった。これにより、独自のソリューションを作ることがしばしば唯一の実用的な選択肢となり、その習慣はブラウザが evergreen （常に最新）になった後も残り続けた。既存のエコシステムへの熟悉も行動を形作る。npmでReactコンポーネントを探すことに慣れた開発者は、プラットフォームソリューションが存在してもまずそれらのツールに手を伸ばす。『ただCSSのposition: stickyを使えばいいんだ、おっとこ』というnpmパッケージは存在せず、代わりにエコシステムは開発者にパッケージされたソリューションを探すように訓練し、ブラウザがすでに提供しているものを考えることを妨げている。文書化の質もこのパターンをさらに強化する。npmパッケージは通常、例やチュートリアル、スクリーンショットを伴う愛情込めた詳細なREADMEを備えているが、ウェブプラットフォームの文書化はかつてブログ、Stack Overflow、CSS Tricksといったサイトに散らばっていた。MDNが権威ある参照となるまで（web.devはより未来志向の補完として）、プラットフォーム機能を学ぶには散在する情報をつなぎ合わせる必要があり、一元的に文書化されたライブラリの方が魅力的に映っていた。実務的な考慮事項を超えて、カスタムソリューションを構築することはしばしば内在的な楽しさをもたらす。たとえば、スクラッチからモーダルダイアログを作る場合、ポジショニング、z-index、オーバーフロー処理、Escキーによる解除、フォーカストラップ、そして起点となる要素へフォーカスを戻すといった理解が必要だ。このプロセスは複雑ながらも深く没頭でき、多くの開発者はこうした問題解決を楽しくて教育的だと感じ、心理学者が言う『IKEA効果』 — 自分で作ったものを完成品よりも高く評価する傾向 — につながる。この楽しさはウェブ開発において歴史的な意義がある。今日、『プラットフォームを使う』ことを最も強く主張する開発者の多くは、かつてポリフィル、シャム、ライブラリ自体を作者としていた。著者は指摘するが、PouchDBなどのプロジェクトを通じてIndexedDB、WebSQL、その他のブラウザストレージAPIに何年も携わった経験が、W3Cの標準化議論に参加するための専門知識を築いた。プラットフォームのギャップを埋める動機がなければ、根底のシステムを深く理解しようとする動機は生まれなかったかもしれない。しかし、プラットフォームを避けることがいつも有益とは限らない。ときには、CSSのような技術が実際にどう動くかを単純に無知していることが原因だ。歴史的に、CSSは直感的でないと見なされてきた — クリアフィックス、フロート処理、min-width: 0のような裏技が必要であり、それが明らかでないため、開発者は命令型ロジックを理解しているために、宣言型スタイルよりもJavaScriptで解決策を実装してきた。何年にもわたり、CSSは行のクランプ、テキストエリアのリサイズ、スクロールバーの非表示といった一般的なパターンを表現する簡単な方法を欠いており、その結果、開発者は馴染みのあるツールでこれらの機能を再創造せざるを得なかった。この現象はウェブ開発に特有のものではない。著者はClickHouseでの類似の経験を説明している。同僚はストレージ前にJSONデータを圧縮しようとし、著者は別のキー値ストアを使うアプローチを試したが、どちらも不要だった。ClickHouseはデータを自動的に圧縮し、カラムナーストアとしてネイティブにストレージを扱うことで横方向の圧縮効率が向上する — これはドキュメントを読み、ベンチマークを構築して初めて気づかれたことだ。今後を見据えて、著者はAIコーディングアシスタントがこのダイナミクスにどう影響するかを考える。楽観的には、大規模言語モデルはプラットフォームについて百科事典級の知識を持ち、自然言語プロンプトを満たすまさに適切なAPIを選択できるかもしれず、テストとベンチマーク後にプラットフォームソリューションを優先する可能性がある。悲観的には、LLMは既存のコードを重複させる傾向があり、ヘルパー関数を再利用するよりもそうなる。開発者が最初のドラフトを十分な代替案の検討なく受け入れたり、オーバーエンジニアリングされたソリューションに対して反復を続けたりすれば、プラットフォーム非idiomaticなコードが増える可能性がある。最終的に、プラットフォームを使うこととカスタムソリューションを構築することの間の緊張は、開発者の成長についてのより深い真理を反映している：エンド・トゥ・エンドでシステム全体の仕組みを理解すればするほど、最小限かつ価値のある貢献をする準備が整う。しかし、スクラッチから何かを作る喜び — 作り手にとって美しいものでも、客観的に優雅でなくても — が、『なぜもっと開発者はプラットフォームを使わないのか？』という問いがプラットフォームがある限り残り続けることを保証している。
Author portrait illustrating the perspective of a developer who has experienced both building custom solutions and advocating for platform use.