現在フロントエンドWeb開発を席巻している小惑星

フロントエンドWeb開発に現在直撃している小惑星

私が尊敬するフロントエンドWeb分野の教育者の多くが、引退するか、活動を縮小しているように見えます。例えば、Axel Rauschmayer、Salma Alam-Naylor、Josh W. Comeauなどです。また、Kent C. Dodds、Addy Osmani、Rachel Nabors、Lydia Hallieといった著名な人物も、フロントエンド開発について語ることから、別の話題へとシフトしています。推測してみてください。

私はWeb開発について話すことで生計を立てたことはありませんが、このブログを持っており、私が興奮するトピックについてカンファレンストークやポッドキャストを行ってきました。例えば最近では、CSSパフォーマンスのあらゆる側面を説明することに情熱を注いでいました。Shadow DOMの仕組み、ブラウザのスタイルエンジンがどのように機能するか、CSS-in-JSの落とし穴などです。

遊び心で、Claude Sonnetに、高い「スタイル計算」コストを持つChromeトレースをどのように処理するか尋ねてみました。これは私の好きな難問の一つです。なぜなら、経験豊富なWeb開発者でさえ、この問題につまずくのを何度も見てきたからです。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. 頻度/増幅

• フレームごとにスタイル再計算を何度もトリガーするもの — 例えば、クラス変更の直後にループ内でスタイル/レイアウトプロパティを読み取る（同期的な再計算を強制する）、またはrAFティックごとに多数のノードに対して.classList.toggle()やインラインstyle更新を使用するJavaScriptアニメーション（バッチ処理するのではなく）。
• バッチ処理せずに、スタイルパスを強制する小さなDOMミューテーションが繰り返される。

4. 継承/計算済みプロパティの伝播

• 継承されたプロパティ（共通の祖先のfont-sizeやcolorなど）を変更すると、レイアウト変更なしでも、すべての下位要素の計算済みスタイルが再計算されます（例: color、visibility、cursorはスタイルのみであり、レイアウトをトリガーしません）。
• 高レベルスコープで変更されたカスタムプロパティ（CSS変数） — :rootや共有祖先で--custom-propを更新すると、それを参照するすべての要素のスタイルが再計算されます。

5. Shadow DOM / コンポーネント境界

• 多数のシャドウルートやスコープ付きスタイルを持つフレームワークを使用している場合、共有されていないスタイルシートのために、コンポーネントインスタンスごとにスタイル再計算が無駄に繰り返されていないか確認してください。

次に測定すべきこと

1. パフォーマンスパネルで「セレクタ統計」を有効にする（歯車アイコン → セレクタ統計を有効にする）。トレースを再度記録します。これにより、スタイル再計算イベントごとに、最も遅いセレクタとマッチカウントが得られます — これにより、どのCSSルールといくつの要素が原因であるかが直接わかります。
2. トレースで「スタイル再計算」イベントのイニシエータ/コールスタックを確認すると、どのJavaScriptがそれをトリガーしたか（クラスのトグル、style.setProperty、アニメーションフレームコールバックなど）がわかります。
3. 再計算ごとに影響を受ける要素の数を数える — DevToolsは、概要ペインでスタイル再計算イベントごとに「影響を受けた要素」を表示します。この数と、実際に外観が変更された要素の数を比較します — 大きな差は、広すぎる無効化を示します。
4. トリガーとなるミューテーションがDOMのどこで発生するかを見る — ルートの近く（広範な無効化）か、小さなサブツリーにスコープされているか（狭く、安価）か。
5. 強制同期スタイルの確認 — 「強制リフロー」の紫色の警告を探します。レイアウトは低いと言っても、DOM書き込みとインターリーブされた強制的なスタイル読み取り（getComputedStyle）が、1回のバッチ処理されたイベントではなく、多数の小さな連続したスタイルイベントとして表示されることがあります。

問題の原因を見つけた後の典型的な修正策

• クラス/状態のトグルを、共通の祖先ではなく、可能な限り最小のサブツリーにスコープします。
• セレクタを単純化し、子孫チェーンよりも単一のクラスセレクタを優先します。
• CSSカスタムプロパティの更新を、必要な最小限のスコープに移動します。
• DOM/クラスの変更をバッチ処理して、再計算がミューテーションごとではなく、一度だけ行われるようにします。
• 独立したサブツリーにcontent-visibility: autoまたはcontain: style layoutを使用して、無効化のスコープを制限します。

今日では、ウェブサイトの読み込みが遅い場合、長年ブラウザパフォーマンスについて書いてきた私でさえ、そして文字通りブラウザパフォーマンスチームで働いていた私でさえ、おそらくClaude CodeにChromeトレースを投げつけて改善点を提案させるでしょう。実際、私は本業でこのことを行っており、いくつかの良い結果を得ています。

フロントエンドの未来

では、フロントエンド開発教育はどうなるのでしょうか？明らかに良い状況ではありません。フロントエンド開発者全体のレベルを引き上げることにやりがいを感じていた人々（私自身を含め）のために、もっと希望に満ちた答えがあればよかったのですが。しかし、いくつか推測はありますし、この問題はまだ探求する価値があると考えています。

中心的な疑問は、この新しい時代においてフロントエンド開発自体がどこに着地するかということです。残念ながら、フロントエンドの知識への投資増加に逆行するいくつかのトレンドがあるように感じられます。

フロントエンドは、エージェントに任せるリスクが低い。 データベース移行をエージェントに書かせる場合、おそらくAIコードレビューを数回経て、自分で精査し、ステージングで実行してから本番に適用するでしょう。しかし、Reactコンポーネントをエージェントに書かせた場合、リスクは（通常）はるかに低く、そのまま本番にデプロイできます。

もちろん、リスクがゼロだと言っているわけではありません。エージェントはアクセシビリティを損なう可能性があり、ユーザーをブロックする無限ループを引き起こす可能性もあります。しかし、一般的に、フロントエンドコードは他の種類のコードよりもはるかに一時的で置き換え可能です。そのため、多くのAIコーダーは、エージェントに監督なしで（良くも悪くも）処理させることに抵抗がないでしょう。

開発者体験（DevExp）の全体的な重要性が低下している。 LLM以前のフロントエンド分野での議論の多くは、エルゴノミクスと成果の間でした。Alex Russellによる「開発者体験」の餌食はその良い例です。別の例として、SvelteとSolidは、そのエルゴノミクスがReactよりも優れた成果（コード量が少なく、パフォーマンスが良いなど）につながると長年主張してきました。

一方、CursorとVigetは、それぞれSolidとLitからReactへのコードベース移行についてブログ記事を書いています。エージェントを使えばリライトのコストは低いので、これは少し驚くかもしれません。なぜよりパフォーマンスが高く、より簡潔なフレームワークに移行しないのでしょうか？その答えは（Cursorの場合は明示的で、Vigetの場合も同様だと推測されます）もちろん、「エージェントはReactを知っている」ということです。良くも悪くも、Reactはトレーニングデータに過剰に代表されており、「エージェント体験」が開発者体験よりも重要になり始めています。

標準が追いつくだろう。 私は数年間、Web標準の分野から離れていますので、これは純粋な推測です。しかし、ウェブサイト構築のエルゴノミクスを改善するための多くの努力（より良いCSSショートハンド、より簡潔なJavaScript構文など）は、パフォーマンスや機能などを実際に向上させるものと比較して、重要性が低いと認識されるようになるでしょう。結局のところ、エージェントがCSSを1行ではなく3行書くことの違いはそれほど大きくなく、 anyway、新しい構文を使用することは、エージェントにトレーニングデータにないことを教えなければならないため、実際にはより困難になる可能性があります。

ある意味では、このシフトはすでに進行中だったのかもしれません。AIコーディングブームのはるか前に、TPACでChromeチームの誰かに、Webコンポーネント標準に取り組んでいると話したことを覚えています。彼らは、それらのAPIは開発者体験にしか影響せず、ブラウザの機能を実際には向上させない（例: Project Fugu）ため、関心がないと答えました。それは私にとって印象的でした。なぜなら、それは良い点だからです。Shadow DOMやカスタム要素のようなAPIは、Web開発者に新しいスーパーパワーを与えるのではなく、コードがどこでどのように作成されるかを変えるだけです。AIコーディングが主流になるにつれて、そのようなものはスポットライトから外れていくと予想されます。

これは、フロントエンド開発者が常に把握しておくべきトピックから標準が消えるという意味ではありませんが、「この新しい構文を使用する」というもの（カンファレンストークや記事の永続的な情報源）から、「ここにこれらの新しい機能があります」というものへと、より焦点を移していくと想像しています。そして、後者のグループは前者よりもはるかに小さくなると予測します。なぜなら、標準化団体にとってより議論の多い傾向があり、利用できる機能のプールもはるかに少ないからです。

フロントエンド教育の行方

では、フロントエンド教育の分野は、この敵対的な未来にどのように適応できるでしょうか？完全に暗くなるのを避けるために、私が考える前向きな方向性をいくつか示します。

まず、エージェントは依然として大局について教育される必要があります。エージェントやハーネスはReact、特にSPAを書くのが好きなようですが、SPAは万能ではありません。マーケティングサイトのためにエージェントに大規模で複雑なSPAを書かせ、その後、バックボタン、フォーカス状態、パフォーマンスなどの問題をすべて修正するために多くのトークンを消費する可能性があります。あるいは、AstroやEleventyのようなMPAフレームワークを選択して、それで済ませることもできます。これらのフレームワークはエージェントにとって少し扱いにくいかもしれませんが（特にAstroはReactに似ていますが、そうではありません）、全体でコード量が約50%少なくなるため、問題にならないでしょう。

第二に、エージェントにとってうまく機能するウェブサイトを作ることが、近い将来、収益性の高い分野になるでしょう。Vercelのis-agenticはその良い例です。皮肉なことに、これは公開されているウェブサイトが本来行うべき良い基本原則（サーバーレンダリングされたコンテンツ、適切なアクセシビリティ、ページの速度など）に戻ることになります。しかし、「AI」という言葉を付けることで人々が気にするようになるのであれば、私はそれに賛成です。

この2番目の点については、少し楽観的ではありません。なぜなら、エージェントがより一般的になるにつれて、ウェブが現在の形で存続するかどうかさえ確信が持てないからです。シアトルからパリへのフライトの費用を知りたい場合、遅いウェブサイトでイライラするボタンの連打をクリックするよりも、エージェントに尋ねたいと思うでしょう。それができない唯一の理由は、これらのウェブサイトがボットを明示的にブロックしているか、MCP（Machine-readable Content Platform）を提供していないからですが、その問題を解決するために躍起になっているスタートアップがいくつかあるはずです。したがって、現在の状況がどれほど持続可能かはわかりません。

第三に、私たちは「バイブコード」の怪物に対するコンサルティングサービスを提供できます。現在、大量のAI生成フロントエンドコードが出力されており、その一部（Claudeの言葉を借りれば）は「ロードベアリング」になるでしょう。それらのウェブサイトが遅く、準拠しておらず、セキュリティホールだらけの場合、エージェントに「ウェブサイトを修正して」と頼むだけでは不十分かもしれません。「ウェブサイトはインターネットでホストされるアプリケーションである」以上の知識がないバイブコーダーにとって、真の専門知識の機会があるかもしれません。

（これは私の3つのポイントの中で最も不確かなものです。なぜなら、2027年または2028年の平均的な専門家を凌駕する次世代の「自己修復型」Webアプリケーションを完全に想像できるからです。しかし、現時点では、専門知識は依然として重要です。）

結論

この記事の目的は、自分自身を慰めることでも、最近のAIブームによって職を失ったすべてのキャリアの墓の上で踊ることでもありませんでした。私は生まれつき悲観的な人間であり、この記事は私自身の悲観主義に浸ることを許容したものです。長年培ってきた膨大な知識がほとんど役に立たなくなったことを指摘しても、私自身は何も感じませんし、私よりもはるかに資格のある同僚に同じことが起こるのを見ても嬉しくありません。しかし、それが起こっていないふりをするのも有効な戦略ではありません。

最近読んでいるブログには、「AIについて話すのにうんざりした」とか「もうAIという言葉を聞きたくない」といったムードがあります。これには、良い区別として身につける、ある種の世をすねた、超越した空気が含まれているのでしょう。しかし、その多くは実際の恐怖から来ていると思います。1年後に何が起こるかわからないことを認めるのは怖いことです。キャリアが特定の軌道に乗って、穏やかに退職を迎えることを想像し、そして目標の数年前にすべてが覆されるのを見るのは不安定です。

私が使っている比喩は、小惑星が地球に衝突し、私たちはまだ瓦礫を調査しているということです。塵が落ち着いた後に何が起こるか（ましてやどの小さな齧歯類が哺乳類の時代をもたらすか！）を予測するのは難しいですが、クレーターを完全に無視することは、最悪の種類の否定と言えるでしょう。別の比喩はCOVIDです。COVIDがヒットしたとき、「うわー、COVIDについて話すのにうんざりした」と思った記憶はありません。代わりに、ウイルス、疫学、マスク着用などについて、知れる限りのことを学びたいと思いました。これは良い考えでした。なぜならCOVIDは今後数年間私の人生を支配することになるからです（その時点で、はい、私もついに話すのにうんざりしました！）。

私には水晶玉はありませんが、この記事は私が最も大切にしている分野が将来どこへ向かうのかを考え抜こうとした試みです。私は、これらの日々では、私の関与ははるかに少なくなっていることを認めます。私はWeb標準から離れ、現在の仕事でもフロントエンドには携わっていません。そして私のブログは、いつものブラウザ、パフォーマンス、アクセシビリティなどのメニューではなく、AIに関する嘆きと歯ぎしりがほとんどでした。それにもかかわらず、私はフロントエンド分野に多くの愛情と尊敬を持っており、その将来に何が起こるかを気にしています。数年後には認識できないほど変わっているかもしれませんが、少なくとも、私の同僚たちがこれらの変化を乗り越え、この奇妙な新しい世界で成功する方法を見つけられることを願っています。