Web開発
現在フロントエンドWeb開発を席巻している小惑星
The asteroid currently hitting front end web development (nolanlawson.com)
要約
多くの著名なフロントエンド開発者や教育者が、AIの台頭によりフロントエンド開発から離れたり、話題を転換したりしています。AIはフロントエンドコードの生成リスクが低いため、開発者体験（DevEx）の重要性が低下し、フレームワーク間の移行コストも低減しています。これにより、フロントエンド開発の教育への投資が減少する可能性があります。
全文翻訳
現在フロントエンドWeb開発を席巻している小惑星
Tea Leaves Software とその他の暗黒魔術、Nolan Lawson著
ホーム アプリ コード 話題 その他 « バグの数は好きなように選べるようになりました » サイボーグにならないこと « 2026年8月23日 フロントエンドWeb開発を席巻している小惑星 Nolan Lawson著 2026年8月23日 Web. タグ: AI. コメント14件
私が尊敬するフロントエンドWeb分野の教育者の多くは、Axel Rauschmayer、Salma Alam-Naylor、Josh W. Comeauなどを例に挙げると、引退するか、活動を縮小しているようです。Kent C. Dodds、Addy Osmani、Rachel Nabors、Lydia Hallieのような他の著名な人物は、フロントエンド開発について話すことから、さて、推測してみてください、について話すことにピボットしました。
私はWeb開発について話すことで生計を立てたことはありませんが、このブログを持っており、私が興奮していることについてカンファレンストークやポッドキャストを行ってきました。最近の例として、私の情熱はCSSパフォーマンスのあらゆる側面を説明することでした。シャドウDOMの仕組み、ブラウザのスタイルエンジン、CSS-in-JSの落とし穴などです。
単なる気晴らしのために、Claude Sonnetに、高い「スタイル計算」コストを持つChromeトレースをどのように処理するか尋ねてみました。これは私の好きな脳トレの一つです。なぜなら、経験豊富な開発者でさえも、何度もつまずくような種類の問題だからです。
Claudeは完全に称賛に値する回答をしました。
クリックしてプロンプトを表示:
インターネットで検索せずに回答してください。Chromeトレースを見ていて、「スタイル計算」コストが高いものの、「レイアウト」コストが比較的低い繰り返しスパンが見られます。最適化のためにWebアプリでどのような点を探しますか？次に何を測定しますか？
「スタイル」コストが実際に表すもの
スタイル（スタイルの再計算）フェーズは、ブラウザがCSSセレクターをDOMにマッチさせ、影響を受ける各要素の最終的な計算済みスタイルを計算するフェーズです。これは、実際に何かが移動したりリサイズしたりするかどうかに関係なく（それはレイアウトの仕事です）、コストがかかります。したがって、スタイルが高いがレイアウトが低い場合、高価なジオメトリではなく、多くの要素にわたるセレクターマッチング/無効化にコストを支払っている可能性が高いです。
Webアプリで探すべきこと
1. セレクターの複雑さと数
複雑すぎる、または深くネストされたセレクター（.a .b .c >; .d + .e）、特に子孫コンビネータは、エンジンにDOM/祖先チェーンをより多く歩かせることを強制します。広範囲に適用されるユニバーサルセレクターまたは属性セレクター（[data-foo="bar"]）。大量のユニークなクラス名/ルールを生成するCSS-in-JSライブラリ（スタイルの再計算は、ルールセット全体を考慮する必要があります）。
2. 無効化スコープ — これは通常、大きな問題です
DOMツリーの高い位置にあるクラス/属性/スタイルのトグル（例: `<body>` またはトップレベルコンテナのクラスをトグルする）は、少数の要素の最終スタイルのみが変更された場合でも、大きなサブツリーのスタイルの再計算を強制する可能性があります。単一の状態変更（例: 「テーマ」クラス、「ローディング」クラス、ホバー状態）が、必要以上に多くの要素を無効化していないか確認してください。Chromeの「セレクター統計」（DevToolsパフォーマンス設定で有効にする）は、どのセレクターが遅く、いくつの要素に対してテストされたかを示します。これは、次に測定する最も有用な指標です。
3. 頻度/増幅
1フレームあたりにスタイルの再計算を何度もトリガーするもの。例えば、クラス変更の直後にループ内でスタイル/レイアウトプロパティを読み取る（同期的な再計算を強制する）、または`rAF`ティックごとに多数のノードで`.classList.toggle()`またはインラインスタイル更新を使用するJavaScriptアニメーション（バッチ処理ではなく）。1回のスタイルのパスを強制する多数の小さなDOMミューテーションをバッチ処理するのではなく、個別に実行すること。
4. 継承/計算済みプロパティの伝播
継承されたプロパティ（親要素のフォントサイズや色など）を変更すると、レイアウト変更なしでも、すべての下位要素の計算済みスタイルが再計算されます（例: 色、表示、カーソルはスタイルのみで、レイアウトはトリガーしません）。高いスコープ（例: `:root` または共有親要素）で変更されたカスタムプロパティ（CSS変数）は、それを参照するすべての要素のスタイルを再計算します。
5. Shadow DOM / コンポーネント境界
シャドウルートやスコープ付きスタイルが多いフレームワークを使用している場合、共有されていないスタイルシートのために、コンポーネントインスタンスごとにスタイルの再計算が無駄に繰り返されていないか確認してください。
次に測定すること
パフォーマンスパネルで「セレクター統計」を有効にする（歯車アイコン → セレクター統計を有効にする）。トレースを再記録します。これにより、各「スタイルの再計算」イベントについて、最も遅いセレクターとマッチカウントが得られます。これにより、どのCSSルールといくつの要素が原因であるかが直接わかります。トレースで「スタイルの再計算」イベントのイニシエータ/コールスタックを確認し、どのJavaScriptがそれをトリガーしたかを確認します。クラスのトグル、`style.setProperty`、アニメーションフレームコールバックなどです。再計算ごとに影響を受ける要素の数を確認します。DevToolsは、サマリーペインで「スタイルの再計算」イベントごとに「影響を受けた要素」を表示します。この数と実際に外観が変更された要素の数を比較します。大きな差は、過度に広範な無効化を示します。トリガーとなったミューテーションがDOMのどこで発生しているかを確認します。ルートに近いか（広範な無効化）、小さなサブツリーにスコープされているか（狭く、安価）です。強制同期スタイルを確認します。「強制リフロー」の紫色の警告を探します。レイアウトが低いと言っても、DOM書き込みとインターリーブされた強制スタイル読み取り（`getComputedStyle`）が、1回のバッチ処理ではなく、多数の小さな連続したスタイルイベントとして表示されることがあります。
原因が見つかった場合の典型的な修正策
クラス/状態のトグルを、共通の親要素ではなく、可能な限り最小のサブツリーにスコープします。セレクターを簡素化し、子孫チェーンよりも単一クラスセレクターを優先します。CSSカスタムプロパティの更新を、必要な最小スコープに移動します。DOM/クラスの変更をバッチ処理して、ミューテーションごとにではなく、一度だけ再計算が行われるようにします。`content-visibility: auto` または独立したサブツリーに `contain: style` を使用して、無効化スコープを制限します。
最近では、読み込みの遅いウェブサイトに直面した場合、長年ブラウザパフォーマンスについて書いてきた人間で、実際にブラウザパフォーマンスチームで働いた経験がある私でさえ、おそらくChromeトレースをClaude Codeに投げつけて改善点を提案させるでしょう。実際、私は仕事でこのことを行い、良い結果を得ています。
フロントエンドの未来
では、フロントエンド開発教育はどうなるのでしょうか？明らかに良い場所ではありません。フロントエンド開発者全員のレベルを引き上げることにかつて多くの満足感を得ていた人々にとって、もっと元気が出るような答えがあればよかったのですが。しかし、いくつかの推測はありますし、問題はまだ解き明かす価値があると思います。
核心的な質問は、この新しい時代においてフロントエンド開発自体がどこに着地するかということです。残念ながら、フロントエンドの知識への投資が増加することに反対するいくつかのトレンドがあるように感じます。
フロントエンドは、エージェントに任せるリスクが低くなっています。データベース移行をエージェントに書かせる場合、おそらくAIコードレビューを数回受けさせ、自分で精査し、ステージングで実行するなどの手順を踏むでしょう。しかし、エージェントでReactコンポーネントを書く場合、それを本番環境に「とりあえず」投入するリスクは（通常）はるかに低くなります。もちろん、リスクがゼロだと言っているわけではありません。エージェントがアクセシビリティを台無しにしたり、ユーザーをブロックする無限ループを引き起こしたりする可能性はあります。しかし、一般的に、フロントエンドコードは他の種類のコードよりもはるかに一時的で交換可能です。そのため、多くのAIコーダーは、エージェントに監督なしで（良くも悪くも）処理させることに満足するでしょう。
DevEx（開発者体験）は全体的に重要性が低下しています。LLM以前のフロントエンド分野での議論の多くは、人間工学と成果の間でした。「開発者体験」の餌食と騙し討ち」Alex Russell著は素晴らしい例です。別の例として、SvelteとSolidは、その人間工学がReactよりも優れた成果（コード量が少なく、パフォーマンスが良いなど）につながると長年主張してきました。一方、CursorとVigetは、それぞれSolidとLitからReactへの移行についてブログ記事を書いています。エージェントを使用すると書き換えのコストが低くなるため、これは少し驚くかもしれません。なぜよりパフォーマンスが高く、より冗長でないフレームワークに移行しないのでしょうか？その答えは（Cursorの場合は明確に、そして私は推測します