https://nolanlawson.com/2026/08/23/the-asteroid-currently-hitting-frontend-web-development/
フロントエンドWebの領域で私が尊敬してきた教育者たちの多くが、身を引くか、活動を縮小させているようだ。アクセル・ラウシュマイヤー（Axel Rauschmayer）、サルマ・アラム＝ネイラー（Salma Alam-Naylor）、ジョシュ・W・コミュ（Josh W. Comeau）など、枚挙にいとまがない。他にもケント・C・ドッズ（Kent C. Dodds）、アディ・オスマニ（Addy Osmani）、レイチェル・ネイバーズ（Rachel Nabors）、リディア・ハリー（Lydia Hallie）といった著名な第一人者たちも、フロントエンド開発について語るのをやめ……まあ、何について語り始めたか想像がつくだろう。
私はWeb開発を語ることで生計を立ててきたわけではないが、このブログを持ち、自分が情熱を感じる事柄についてカンファレンスでの登壇やポッドキャスト出演を行ってきた。例えば最近では、CSSパフォーマンスの細部を解説することに情熱を注いでいた。Shadow DOMの仕組み、ブラウザのスタイルエンジンの仕組み、CSS-in-JSの罠などである。
気まぐれに、私はClaude Sonnetに対し、「スタイル計算（Style Calculation）」のコストが高いChromeのパフォーマンストレースにどう対処するか尋ねてみることにした。これは私のお気に入りの難問の一つである。なぜなら、Web開発者たち――それも経験豊富な開発者たちでさえ！――が何度も何度もつまずくのを見てきた類の課題だからだ。Claudeは驚くほど見事な回答を返してきた：
クリックして表示
プロンプト： インターネットを検索せずに答えてください：Chromeのパフォーマンストレースを見ていて、レイアウト（Layout）コストは比較的低いのに、スタイル（Style）コストが高い区間が何度も繰り返されているのを発見しました。最適化のためにWebアプリのどのような点を確認しますか？次に何を測定しますか？
スタイル（Recalculate Style）フェーズとは、ブラウザがDOMに対してCSSセレクタをマッチングし、影響を受ける各要素の最終的な計算済みスタイル（Computed Style）を算出する処理である。実際に要素が移動したりサイズ変更されたりしたか（それはレイアウトの役目である）とは無関係にコストが発生する。したがって、Styleが高くLayoutが低い場合、重いジオメトリ計算ではなく、多数の要素にわたるセレクタのマッチングと無効化（Invalidation） にコストを支払っている可能性が高い。
1. セレクタの複雑さと数
- 過度に複雑または深くネストされたセレクタ（
.a .b .c > .d + .e）、特に子孫結合子は、マッチング試行ごとにエンジンに対してより多くのDOM/先祖チェーンの探索を強制する。- 広範囲に適用された全称セレクタや属性セレクタ（
[data-foo="bar"]）。- 膨大な数の一意なクラス名やルールを生成するCSS-in-JSライブラリ（スタイルの再計算はルールセット全体を走査しなければならない）。
2. 無効化のスコープ（範囲） — 通常これが最大要因
- DOMツリーの高い位置でのクラス/属性/スタイルの切り替え（例:
<body>やトップレベルのコンテナでのクラストグル）は、たとえ最終的なスタイルが変わる要素がごく一部であっても、巨大なサブツリー全体でスタイルの再計算を強制する可能性がある。- 単一の状態変更（例: 「テーマ」クラス、「ローディング」クラス、ホバー状態）が必要以上に多くの要素を無効化していないか確認する。Chromeの「Selector Stats」（DevToolsのPerformance設定で有効化）を使用すれば、どのセレクタが遅く、何個の要素に対してテストされたかが表示される――これが最も有用な測定である。
3. 頻度と増幅
- 1フレームあたり何回もスタイルの再計算をトリガーしている処理――例えば、クラス変更直後にループ内でスタイル/レイアウトプロパティを読み取る処理（強制的同期再計算が発生する）、またはバッチ処理を行わずに1回のrAFティックごとに多数のノードで
.classList.toggle()やインラインのstyle更新を行うJSアニメーション。- 1回にバッチ化されず、個別にスタイルパスを強制する小さなDOM変更の繰り返し。
4. 継承プロパティおよび計算済みプロパティの伝播
- 共通の先祖で継承プロパティ（
font-sizeやcolorなど）を変更すると、レイアウトの変更を伴わなくても全子孫の計算済みスタイルの再計算が強制される（例:color、visibility、cursorはStyleのみで、Layoutをトリガーしない）。- 高レベルのスコープで変更されたカスタムプロパティ（CSS変数）――
:rootや共有の先祖で--custom-propを更新すると、それを参照するすべての要素のスタイルが再計算される。5. Shadow DOM / コンポーネント境界
- 多数のShadow Rootやスコープ付きスタイルを持つフレームワークを使用している場合、共有されていないスタイルシートが原因で、コンポーネントインスタンスごとにスタイルの再計算が無駄に繰り返されていないか確認する。
- Performanceパネルで「Selector Stats」を有効化する（歯車アイコン → Enable selector stats）。トレースを再記録する。これにより、Recalculate Styleイベントごとに、最も遅いセレクタとマッチ試行回数が得られる――どのCSSルールといくつの要素が原因であるかが直接判明する。
- トレース内の「Recalculate Style」イベントの開始元/コールスタックを確認する――どのJSがそれをトリガーしたか（クラスの切り替え、
style.setProperty、アニメーションフレームのコールバックなど）。- 再計算ごとに影響を受ける要素の数をカウントする――DevToolsはサマリーペインでRecalculate Styleイベントごとに「Elements Affected」を表示する。その数と実際に外見が変わった要素の数を比較する――大きな乖離があれば過剰に広範な無効化を示している。
- DOM内のどこで変更が発生したかを観察する――ルート付近（広範囲の無効化）か、小さなサブツリーにスコープされているか（狭く、安価）。
- 強制的同期スタイル（Forced synchronous style）をチェックする――「Forced reflow」の紫色の警告を探す。Layoutが低いと言っても、DOM書き込みの合間に強制的なスタイル読み取り（
getComputedStyle）が挟まれると、1つのバッチ化されたイベントではなく、多数の小さな連続したStyleイベントとして現れることがある。
- クラスや状態の切り替えを共通の先祖ではなく、可能な限り最小のサブツリーにスコープする。
- セレクタを簡素化し、子孫チェーンよりも単一のクラスセレクタを優先する。
- CSSカスタムプロパティの更新を必要最小限のスコープに移動する。
- DOM/クラスの変更をバッチ処理し、変更ごとではなく1回だけ再計算が発生するようにする。
- 独立したサブツリーに
content-visibility: autoやcontain: style layoutを使用して無効化スコープを制限する。
昨今、読み込みの遅いWebサイトに直面した場合、長年ブラウザのパフォーマンスについて執筆し、文字通りブラウザのパフォーマンスチームで働いていた人間である私でさえ、おそらくChromeのトレースをClaude Codeに投げつけて改善案を出させるだろう。実際、本業の仕事でまさにそれを実行し、素晴らしい結果を得ている。
では、フロントエンド開発の教育はどこへ向かうのだろうか？当然ながら、明るい場所ではない。かつて（私のように）世界中のフロントエンド開発者の水準を引き上げることに大きな充実感を覚えていた人たちに対して、もっと元気づけられるような答えがあればよかったと思う。しかし、私にもいくつか推測があり、この問題は依然として深く考える価値があると思っている。
核心となる問いは、この新しい時代においてフロントエンド開発そのものがどこに着地するのかということだ。悲しいことに、フロントエンドの知識への投資拡大に逆行するいくつかのトレンドが存在するように私には感じられる：
フロントエンドは、エージェントにそのまま丸投げしてもリスクが低い。 エージェントを使ってデータベースのマイグレーションを書く場合、おそらく何回ものAIコードレビューを重ね、自ら精査し、まずステージング環境で実行するだろう。しかし、エージェントでReactコンポーネントを書く場合、そのまま本番環境に「YOLO（勢いで投入）」することのリスクは（典型的には）はるかに低い。
リスクがゼロだと言っているわけではない点に注意してほしい：エージェントはアクセシビリティを壊すかもしれないし、ユーザーをブロックする無限ループを引き起こすかもしれない。しかし一般的に、フロントエンドコードは他の種類のコードに比べてはるかに儚く、代替が容易である。そのため、多くのAIコーダーは（良くも悪くも）エージェントに監視なしで任せることに抵抗を感じなくなるだろう。
開発者体験（DevExp）の重要性が全体的に低下している。 LLM以前のフロントエンド界隈における議論の多くは、エルゴノミクス（使い勝手）対成果に関するものだった。Alex Russellによる「『開発者体験』という名のすり替え（The 'developer experience' bait-and-switch）」はその好例である。別の例として、SvelteやSolidは、そのエルゴノミクスがReactよりも優れた成果（コード量の削減、パフォーマンスの向上など）をもたらすと長年主張してきた。
一方、Cursor や Viget は、自社のコードベースをそれぞれSolidやLitからReactへと移行したことについてブログに書いている。エージェントを使えば書き直し（リライト）のコストが下がるため、これは少し意外に思えるかもしれない：なぜより高性能でボイラープレートの少ないフレームワークに移行しないのか？その答えは（Cursorの場合は明示的に、そしてVigetもおそらく同様だが）当然ながら**「エージェントがReactを知っているから」**である。良くも悪くも、Reactはトレーニングの重みの中で過剰に代表されており、開発者体験よりも「エージェント体験（Agent Experience）」の方が重要になり始めているのだ。
標準化が追いつく。 私はWeb標準の世界を離れて数年になるので、これは完全に私の推測に過ぎない。しかし、Webサイト構築のエルゴノミクスを改善するための多くの努力――より良いCSSのショートハンド、より簡潔なJavaScriptの構文など――は、パフォーマンスや機能などを実際に向上させる事柄に比べて重要性が低いと見なされるようになるのではないかと思う。結局のところ、エージェントにとってCSSを1行ではなく3行書くことに大差はないし、いずれにせよ新しい構文を使用することは、エージェントのトレーニング重みに含まれていない事柄を指示しなければならないため、実際にはより困難にすらなり得る。
ある意味で、この変化はすでに始まっていたのかもしれない。数年前、AIコーディングブームが起きる遥か前のTPACで、Chromeチームの人物にWebコンポーネント標準に取り組んでいると話したときのことを覚えている。彼らはそれに興味がないと答えた。なぜなら、それらのAPIは開発者体験に影響を与えるだけで、実際にブラウザの能力を向上させるわけではないからだ（例: Project Fugu）。それは良い指摘だったので私の心に残った：Shadow DOMやCustom ElementsのようなAPIは、Web開発者に新しいスーパーパワーを与えるものではなく、コードがどこでどのように書かれるかを変えるだけに過ぎない。AIコーディングが主流になるにつれ、そうしたものは脚光から遠ざかるだろうと私は予想している。
これは、フロントエンド開発者が把握しておくべきトピックから標準化が消え去ることを意味するのではない。しかし、「この新しい構文を使おう」（カンファレンスのトークや記事の不朽のネタだった）ということよりも、「登場しつつある新たな機能群はこれだ」という内容にシフトしていくと思われる。そして後者のグループは前者よりもはるかに小さいと予測する。標準化団体にとってより議論の余地が大きく、引き出せる機能のプール自体が小さいからだ。
では、フロントエンド教育という分野は、この過酷な未来にどのように適応できるのだろうか？完全に絶望的な気持ちにならないために、私が進む可能性があると考える前向きな方向性をいくつか挙げてみる。
まず第一に、エージェントには依然として「大局的な視点」を教育する必要がある。エージェントやハーネスはReact、特にSPA（シングルページアプリケーション）を書くのが大好きなようだが、SPAは万能の解決策ではない。マーケティングサイトのためにエージェントに大規模で複雑なSPAを書かせ、「戻る」ボタン、フォーカス状態、パフォーマンスなどのバグ修正に膨大なトークンを燃やすこともできるし、あるいは単にAstroやEleventyのようなMPA（マルチページアプリケーション）フレームワークを選んで手仕舞いにすることもできる。これらのフレームワークはエージェントにとって少し扱いづらいかもしれないが（特にAstroはなんとなくReactに似ているが実際は異なるため）、全体として書くコードの量が約50%減るため、問題にはならないだろうというのが私の推測だ。
第二に、「エージェントにとって適切に機能するWebサイト」を作ることは、近い将来において実りある取り組みになる可能性が高い。Vercelの is-agentic はその好例である。皮肉なことに、これは公開Webサイトが本来最初から実践しておくべきだった優れた基礎へと回帰することを示している：サーバーレンダリングされたコンテンツ、適切なアクセシビリティ、ページ速度などである。しかし、「AI」という言葉を冠することが人々の関心を引くきっかけになるのであれば、私は大賛成だ。
ただし、この第二の点については私自身それほど楽観視していない。なぜなら、エージェントが普及するにつれて、Webが現在の形のまま存続できるかどうかも定かではないからだ。シアトルからパリへの航空券の価格を調べたいとき、読み込みの遅いWebサイト上でイライラさせられる一連のボタンをクリックするよりも、エージェントに尋ねる方がはるかに良い。現在それができない唯一の理由は、それらのWebサイトがボットを明示的にブロックしているか、あるいはMCPを提供していないからに過ぎないが、その問題を解決しようと手ぐすね引いているスタートアップがいくつもあるはずだ。そのため、現状がどれほど持続可能かはわからない。
第三に、「バイブコーディング（Vibe-coding）が生み出した怪異」に対するコンサルティングサービスを提供することだ。現在、膨大な量のAI生成フロントエンドコードが世に送り出されており、その一部は（Claude風の表現を借りれば）確実に「荷重がかかる重要構造（load-bearing）」となるだろう。それらのWebサイトが遅く、標準に準拠しておらず、セキュリティホールだらけである場合、エージェントに「サイト直して」と頼むだけでは不十分かもしれない。特に大金がかかっており、バイブコーダーのWeb開発知識が「Webサイトとはインターネット上でホストされているアプリのこと」というレベルを超えない場合、本物の専門知識にビジネスチャンスが生まれる可能性がある。
（ただし、2027年や2028年には「自己修復（Self-healing）」機能を備えた次世代Webアプリが登場し、並の専門家を凌駕する未来も完全に想像できるため、これが3つの論点の中で最も脆弱であることは認める。しかし当面の間は、専門知識は依然として重要である。）
この投稿の目的は、自分自身を慰めることでも、昨今のAIブームによって覆されたすべてのキャリアの墓前で踊ることでもない。私は根が暗い人間であり、この投稿は自分自身の陰鬱さに浸ることを許した結果である。長年積み上げてきた膨大な知識体系がほぼ時代遅れになったことを指摘して悦に入っているわけでもないし、自分よりもはるかに優秀な同僚たちに同じことが起きているのを見て喜んでいるわけでもない。しかし、それが起きていないかのように装うこともまた、正しい戦略ではない。
昨今私が読んでいるいくつかのブログには、「もうAIの話にはうんざりだ」「二度とAIの話題を振らないでくれ」といったムードが漂っている。その一部は、世をすねた超然とした態度であり、自らを特別に見せるバッジとして身につけるのが心地よいのだろう。しかし、その多くは本物の恐怖から来ているとも私は思う。1年後に何が起きるかわからないと認めるのは恐ろしいことだ。自分のキャリアがある軌道に沿って進み、穏やかに引退を迎えられると思い描いていたのに、ゴールまであと数年というところで全てがひっくり返るのを見るのは精神を不安定にさせる。
私が使ってきた比喩は、「巨大な小惑星が地球に衝突したばかりで、私たちは今なおその残骸を調査している最中である」というものだ。塵が収まった後に何が起きるかを予測することは困難であるし（ましてやどの小型齧歯類が哺乳類時代を切り拓くかなど！）、クレーターの存在そのものを無視することは最悪の現実逃避に思える。もう一つの比喩は新型コロナウイルス（COVID）である。COVIDが流行したとき、「うっ、もうコロナの話はうんざりだ」と思った記憶はない――むしろ、ウイルス、疫学、マスクなどについて学べる限りのことを学びたいと思った。結果としてこれは良い判断だった。なぜならCOVIDはその後数年間にわたって私の人生を支配することになったからだ（その時点で、はい、私もついにその話題にうんざりしたわけだが！）。
私に水晶玉があるわけではないが、この投稿は私が最も大切にしてきた分野が今後どこへ向かうのかを熟考しようとした私の試みである。近頃の私は、この分野に対する利害関係（Skin in the game）をかなり失っていることは認める：私はWeb標準の活動から離れ、現在の職場ではフロントエンドにすら携わっておらず、私のブログはブラウザ、パフォーマンス、アクセシビリティといったいつものメニューではなく、AIに関する嘆きと歯ぎしりばかりになっている。それでもなお、私はフロントエンドという分野に対して深い愛と敬意を抱いており、その未来に何が起こるかを気にかけている。わずか数年で認識すらできない姿に変わってしまうかもしれないが、せめて私の仲間たちがこれらすべての変化を乗りこなし、この奇妙な新世界で繁栄する方法を見出してくれることを願っている。