なぜもっと多くの開発者は「プラットフォーム」を利用しないのか？

元記事: 2026年10月4日原文(nolanlawson.com)

概要

「use the platform」 という標語がなぜ必要とされ続けるのかを多角的に考察
歴史的背景や開発者の習慣、学習曲線が自作志向を生む理由を解説
サードパーティ製ライブラリとプラットフォームAPIの使い分けの現実
AIコーディング が今後この現象に与える可能性を楽観・悲観両面から分析
「use the platform」が今後も語られ続ける理由をまとめ

「use the platform」とは何か、その背景

Web標準、パフォーマンス、アクセシビリティ推進派による「use the platform」の呼びかけ
ブラウザ標準機能 を使うことで性能・ユーザビリティ向上を期待
歴史的には jQuery等ライブラリ が標準APIの穴埋め役
IE6等のレガシーブラウザ 対応のため独自実装が合理的だった時代背景
現在は多くのブラウザが エバーグリーン化 し状況改善

ライブラリ利用とプラットフォームAPIの使い分け

npmでReactコンポーネント を探す習慣が根付いている現状
標準APIよりも ドキュメントや事例が豊富 なサードパーティ製ライブラリ
Dragula等のUIライブラリ とMDN公式ドキュメントの比較
React開発者 が低レベルAPIを直接触るのを敬遠する傾向
経験豊富な開発者 が標準APIをラップしてコンポーネント化する分業体制

自作志向の心理と学習効果

自作の楽しさ や理解しやすさから独自実装を選ぶ開発者層
IKEA効果 による自作コードへの愛着
例： モーダルダイアログ の自作過程と学び
標準APIが存在しない時代の 学習手段としての自作
polyfillやshim の作者が後に「use the platform」推進派になる事例

独自実装の問題点とCSSの学習障壁

CSSの難解さ がJavaScript実装の増加を招いた歴史
直感的でない CSSのトリック や過去の制限
命令的思考 でJavaScriptに頼る傾向
新しいCSS機能の登場で状況が徐々に改善

他プラットフォームにも共通する現象

Web以外 でもプラットフォームAPIの理解不足による独自実装が発生
例： ClickHouse での誤ったデータ圧縮手法
公式ドキュメントの読解とベンチマークで 標準機能の優位性 を実感
経験豊富なエンジニアほど シンプルな解決策 を選択

AIコーディング時代の「use the platform」

LLM（大規模言語モデル） による最適なAPI選択の期待
AIが既存コードを無視し冗長な実装 を増やす懸念
テストや最適化不足 で非効率なコードが量産される危険性
AI活用の実体験 から両極端な結果が生まれる現状

「use the platform」の今後

「use the platform」 はシンプルで力強い開発指針
過剰な独自実装 よりも標準機能活用の重要性
自作の楽しさ や学習効果も否定できない
今後も プラットフォームが存在する限り 語られ続けるテーマ
FediverseやLobsters での議論も推奨

提供: ハクソク · 要約更新: 2026年10月5日

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

なんか歴史的な偶然みたいな気がする。昔はプラットフォームが全部できなかったから、ダイアログが必要なときはライブラリを使わなきゃいけなかった。開発者たちは、ダイアログみたいなものが必要なときはライブラリを使うのが普通だと教えられてたんだよね。それでReactが登場してから、React以降にウェブ開発を学んだ人たちはプラットフォームについてほとんど知らない。DOMに触れるのは良くないことだって教えられたし。それが全てかな。今でもバニラCSSを推奨すると、横目で見られて「TailwindやShadcnがデフォルトであるべき」って言われる。分かるよ、みんなが慣れてるのはそういうものだし、プラットフォームよりも劣ってるとしてもね。

└

TailwindやShadcnがプラットフォームより劣ってるってどういうこと？開発が桁違いに速くなるよ。

一つ言えるのは、WebComponentsは設計が悪くて使いにくいAPIだと思ってるってこと。実際、Litとかもっと大きなものなしでWebComponentsを使ってる人ってどれくらいいるんだろう？Reactは比較的よく設計されたライブラリで、そんなに重くないと思う。議論する意味はあんまりないけど、これは主観的な問題だから、価値観の違う人たちはどうしても意見が合わないよね。でも、そういう立場を持ってる人を尊重しないと、合意に向けて進展はないよ。最近、（Reactの）アプリケーションで使おうとしたんだけど、結構うまくいった。でもFirefoxではフェードインのアニメーションしか実質的にできないことが分かった。フェードアウトは無理なんだよね。それが致命的な問題ってわけじゃないけど、ちょっと残念だなと思った。APIの形も変だと思うし、嫌いってわけじゃないけど、好きでもない。Reactを好む開発者が最適じゃない選択をしてるっていう暗黙の見方は、ちょっと上から目線で、他の視点から物事を見ようとする精神に反してると思う。強い主張に焦点を当てるべきじゃない？WebComponentsやShadow DOMについて文句を言ってる人を見たことがないなら、それは驚きだよ。HNではWebComponentsに対する批判を結構見かけるし。あ、ちなみに、この記事はWebComponentsを直接名指ししてないけど、特にWebComponentsに焦点を当ててるのは自覚してるよ。でも、Reactを捨てて伝統的なDOM APIの上に自分たちのコンポーネントフレームワークを実装するって話じゃないよね。だって、Reactがもうそれをやってるから。

└

WebComponentsは設計が悪くて使いにくいAPIだと思ってるこれを見た瞬間、まさにその通りだと思った。俺は25年以上フロントエンドのコードを書いてるけど、その間に本当に嫌になってやめたくなることがあったのは、Internet Explorer 6とWebComponentsの2つだけだ。毎回「プラットフォームを使おう」とすると、嫌になってモチベーションが下がって、再挑戦しようとしたサイドプロジェクトをやめちゃう。ウェブプラットフォーム自体は好きなんだけど、WebComponentsはその熱意を完全に奪っちゃう。エージェント開発の時代でも、AIはWebComponentsの同じ足元の罠に引っかかるし。関係者全員が「はい、そして…」って基準を追加してるだけで、実際にウェブ開発者がどう使うかを考えたことがないように見える。

└

Reactは比較的よく設計されたライブラリで、そんなに重くない俺はその意見には全く賛成できない。SvelteやSolidJSの方が明らかに技術的に優れてると思う。でも、Reactがまだ人気なのはなぜかっていう疑問が残る。最大の理由は、Reactの非技術的な側面だと思う。 - 彼らは素晴らしいドキュメントを持ってるし、初日からそうだった。 - 動画やサンプルプロジェクト、あらゆる「始め方」のドキュメントを作った。 - Reactカンファレンスを開催して、誰にでも「1方向のデータフロー」について教えて、FPを発明したかのように振る舞った。その盛り上がりは、本当に次の大きなもののように感じさせた。資金が豊富なReactチームと外部の開発者コミュニティの間には、本物の勢いがあった。みんながこぞって学んで、学生に教えて、ウェブサイトを作った。Reactの設計上の問題が影響を及ぼしたとき（たくさんの問題があったけど）、それを間違って使ったせいにされた。コンポーネントクラス、ステート、CSS、フック、WebpackやBabelの遅さ、大きなバンドルサイズ、遅い再レンダリングなど。次世代のJSフレームワークが登場したとき、コミュニティからはため息が漏れた。「またかよ、ウェブサイトの作り方を再学習したばかりなのに。」Reactは波だったし、その後にはフレームワーク疲れがあった。ソフトウェアが人気になるには、熱心な人たちの多くの努力が必要だよね。基準を作る人たちの仕事は本当に尊敬してるけど、彼らはドキュメントや動画、チュートリアル、スタータープロジェクト、ブログ、ポッドキャストなどを作る時間をほとんど取らないんだよね。

└

俺は頑なにReactを避けてきた。ネイティブのWebComponentsが登場したとき、維持している小さな内部サイトで試してみようと思ったんだ。そしたらすごく遅かった。重複コードを減らそうとした結果、サイトの読み込みが瞬時から目に見える読み込み時間に変わっちゃった。組み込み機能の最も基本的な実装を最適化して速くするためにトリックを使わなきゃいけないのは間違ってると思ったから、全部捨てて昔の構造に戻った。

└

WebComponentsの何が気に入らないの？例えば、クリックすると何回クリックされたかを表示するアイコンを作りたいとするじゃん。WebComponentのコードは結構まともに見えるけど：

class HelloIcon extends HTMLElement {
  connectedCallback() {
    this.clickCount = 0;
    this.innerHTML = ` :) こんにちは、私は0回クリックされました 閉じる `;
    const icon = this.querySelector('.icon');
    const dialog = this.querySelector('dialog');
    const closeBtn = this.querySelector('.close');
    const dialogText = this.querySelector('p');
    icon.addEventListener('click', () => {
      this.clickCount++;
      dialogText.textContent = `こんにちは、私は${this.clickCount}回クリックされました`;
      dialog.showModal();
    });
    closeBtn.addEventListener('click', () => dialog.close());
  }
}

ここで試してみて: https://plnkr.co/edit/0XUOLyM52xfFiIBu?open=index.html&previ...

└

ウェブコンポーネントのAPIの何が悪いの？既存のプラットフォームの現実を考えると、どうすれば違った形にできたのかな？

└

StencilやLitは基本的に必須だね。

└

APIがこんなにひどいとは驚きだよ。Shadow DOMはほとんどすべてを悪化させる。うちのフロントエンドチームはLitの使用をやめたから、全体のアイデアの馬鹿さ加減をそのまま味わってる。スタイルのカプセル化？それはあるけど、完全じゃないし、どの部分が使えないのか探すのも大変。状態管理？クエリセレクタに戻ることになるけど、これも影の中に入るときは動作が悪くて、回避策が必要になる。だから、DOMを状態として使うことにした。これについては話したくない。スロット？モダンなフレームワークから来たら、スロットは明らかに後退だよ。Reactではコンポーネントをプロップとして渡せるけど、Shadow DOMの世界ではHTMLで示さなきゃいけない。スロットがいくつもあれば、動作を合わせるために無駄に冗長になる。プラットフォームを直接使うことは、静的な検証可能性を失うことにもなるし、もう誰もこれについて話す必要はないけど、addEventListenerを厳格に使うことでプラットフォームに忠実でいると、要素にイベントハンドラが存在することを要求できなくなる。みんなこれを忘れがちだけど、ブラウザが何かをするためのデフォルトの方法は、信頼性にとって大きな足かせになる。うちのフロントエンドチームの失敗から学んで、走って逃げるべきだよ。

└

Reactが膨れすぎてないってどういうこと？初回のウェブサイト訪問でフルダウンロードが必要なんだから、ウェブコンポーネントはブラウザネイティブだよ。別にウェブコンポーネントが良いとは言わないけど、Reactが膨れすぎてないって言うのは侮辱だよ。昔はjQueryを入れるかどうか慎重に考えてた時代もあったんだから。

└

WebComponentsはReactへの反発から生まれたもので、中世のアーティストが馬を描くときに、実際に馬を見たことがないかのようなものだよ。

Hacker Newsで議論の続きを見る