なぜ開発者はブラウザ標準を使わないのか

2026年10月3日、開発者のNolan Lawson氏が自らのブログで「use the platform」が定着しない理由を論じた論考を公開した。Lobsters の nolanlawson.com by nolan の報道では、同氏が長年ウェブ標準や性能、利用しやすさの観点から標準機能の利用を唱えてきた経緯が示されている。

同氏の主張は明快だ。ブラウザが標準で提供する機能をわざわざJavaScriptで再実装する必要はない。自作の実装は性能や操作性の面で劣る可能性が高い。にもかかわらず、多くの開発者が説得を必要とする現状に、同氏は相手側の視点を検討する必要性を説いた。

why build something yourself, in JavaScript, when the browser can do it for you?

この問いかけは、標準推進派の基本的な立場を表している。今回の論考は、その立場が自明であるにもかかわらず普及しない要因を歴史や慣習、文書の面から整理した点に特徴がある。

ブラウザ実装の遅れと歴史的経緯

標準機能の利用が進まなかった第一の要因として、ブラウザ実装の歴史的な遅れが挙げられている。長期間にわたり、ブラウザは上位の生態系に追随する立場にあった。jQueryのようなライブラリが決定的な空白を埋めた。ブラウザが同等のAPIを実装した後も、IE6のような旧式環境が残存する限り、開発者は標準だけに依存できなかった。

2020年代に入り、多くのブラウザは常時更新型に移行した。Safariの更新頻度には議論が残るものの、年間7回程度の更新は維持されている。現在の環境では標準機能の利用条件は整いつつある。一方で、それ以前の不均質なウェブ環境を経験した開発者にとって、自前実装は合理的な選択だった。

この履歴は組織の記憶として残存している。動作保証や後方互換性の確保を優先する現場では、検証済みの実装を継続する判断が選ばれる。標準が整備されても、過去の苦労を背景とした慎重姿勢は容易に変わらない。歴史的経緯は単なる過去の話ではなく、現在の選好を規定する要素だ。

プラットフォーム側の提供と現場の採用には時間差がある。Windows 11にOneDrive Photosが勝手インストール、削除不能にが示すように、基盤側が用意した機能が現場の期待とずれる事例は少なくない。ブラウザ標準も同様に、実装の存在と実務での信頼は別の問題として受け止められている。

npm生態系の利便性と慣習の壁

第二の要因は、npmを中心とした開発慣習の強さだ。Reactの構成部品を探す行為に慣れた開発者は、課題の性質にかかわらず同じ手法を選ぶ。npmで粘着設定を検索しても、「CSSのposition: stickyを使え」と助言する包は現れない。検索と導入の経路自体が外部依存の選択を促す構造にある。

枠組みと基盤の間には使いやすさの溝がある。堅牢な標準が存在しても、枠組み向けの使い勝手を整える包が有用な橋渡しを担う。標準APIを直接扱うよりも、慣れた記法で扱える抽象化が選ばれるのは自然な流れだ。

React開発者の行動もこの傾向を裏付けている。JSXやReact流の記法に固執する一方で、生のDOM操作は避けたい対象とされる。直接的なDOM APIには抵抗感がある。それにもかかわらず、仮想化一覧のような性能重視のライブラリが内部で生のDOM操作を用いることには寛容だ。

表層の開発体験と内部の実装手段が分離している。初学者にも扱いやすい上位の部品が提供されれば、内部の低水準処理は問題視されない。生態系は熟練者が基盤APIを包み直し、初学者が利用しやすい形状で配布する分担を生んだ。この分担は効率的である反面、基盤への関心を薄める作用を持つ。

開発文書の整備状況と訴求力の差

第三の要因は文書の整備状況にある。多くのnpm包は丁寧な説明文書や公式サイトを備える。使用例や手順、画面図が揃い、導入までの道筋が明確だ。比較検討や導入判断に必要な情報が一か所に集約されている。

一方で、ウェブ基盤の文書は長く分散していた。個人のブログやStackOverflow、CSS Tricksのような解説サイトに情報が散らばった。MDNが参照先として定着し、Googleのweb.devが将来志向の発信を担う体制になるまで、一貫した案内は得難かった。

分散期の解説は外部依存の利用を推奨することも多かった。jQueryやGreenSockの利用が定番の解法として示された。基盤の標準機能よりも、枯れた外部手段の方が確実だとの受け止めが広がった。

具体例として、DragulaのサイトとMDNのドラッグアンドドロップ解説の対比が挙げられている。前者の訴求力は依然として高いとの評価だ。機能の正しさとは別に、提示の巧拙が選択を左右する。文書の質と体験設計は、技術の優劣と同じ重みで採用を決定づける。

役割分担と抽象化がもたらす効用

論考が示す分担構造は、単なる怠慢では説明できない。枠組み利用者は基盤の詳細を隠蔽されることで生産性を上げている。仮想化や描画の最適化など、性能が厳密に問われる領域は専門家が担う。一般の開発者はその成果を部品として消費する。この階層化は大規模開発の要請に合致する。

抽象化は学習費用を下げる。生のDOM APIや仕様書の読解を経ずに、目的の挙動を実現できる。期限や人員に制約がある現場では、この短縮効果が優先される。標準の直接利用が理想だとしても、費用対効果の判断では部品利用が勝つ場面がある。

枠組みの流儀への同調も無視できない。JSXに慣れた集団では、標準的な記述が異物として扱われる。符号の統一や審査の容易さを考えれば、流儀に沿った部品が選ばれる。技術的な正しさと集団の保守性は別の評価軸だ。

この構造では、基盤の知識が一部の担い手に集中する。多くの開発者は基盤を意識せずに成果を得られる。問題が起きた際の調査能力や置換可能性は低下する。効率と理解の交換が常態化している点に、標準推進派の懸念がある。

標準機能に対する不信と残る課題

標準への距離感は、単なる知識不足ではない。過去に標準が不完全だった経験、文書の分散、訴求力の差が積み重なった結果だ。開発者は合理的に外部手段を選んできた。その判断様式が更新型ブラウザの時代にも残っている。

標準側にも課題がある。仕様の策定から実装、文書化、普及までの過程が長い。外部包のような機敏な改善や魅力的な提示に欠ける。機能が存在することと、現場で使いたいと思わせることは異なる。後者の設計が不足している。

今後の焦点は、標準機能の発見可能性と導入体験にある。検索した際に標準の解法が最初に示されるか。公式文書が具体例とともに即戦力の情報を提供するか。枠組み向けの橋渡しが公式に用意されるか。これらの条件が揃わない限り、外部依存の慣性は続くと見られる。

論考は標準推進を否定していない。むしろ、推進側が相手の事情を理解する必要性を説いている。性能や利用しやすさの正論だけでは行動は変わらない。歴史、慣習、文書、分担の実態に向き合うことが、普及への近道になる。

編集部の見解

短期的影響として、標準機能と外部包の併用は今後3〜6か月も続くと見る。現場は検証済みの依存関係を外さない。文書の訴求力が高い包が選ばれ続ける。ブラウザの更新だけでは選好は変わらないと評価する。各組織は置換費用を測り、段階的な見直しに留めると見る。

長期的視点では、1〜3年で基盤知識の偏在が課題になると見る。抽象化の背後で標準の理解が進まない。障害対応や性能調整で差が生じる。教育や文書整備が追いつくかが分岐点になると評価する。公式文書の体験改善が進めば、標準回帰が起きる可能性もあると見る。

編集部からの問いとして、誰が橋渡しを担うべきかが問われていると考える。枠組み向けの使い勝手を標準側が用意すべきか。有志の包に委ねるべきか。発見可能性を検索や文書の側でどう担保するのか。これらの設計思想が定まらない限り、掛け声だけでは普及しないのではないだろうか。

参考

• 「Why don’t more developers “use the platform”?」, by nolanlawson.com by nolan — Lobsters, 2026-10-03T21:35:28.000Z (ARR)
• 元記事URL: https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/