MDNがReactを捨てた。彼らが代わりに使ったものとは。

ウェブで最も信頼されているドキュメントサイトが、React製のフロントエンドをすべて捨てた。彼らの新しいスタックは、ネイティブブラウザ技術への根本的な賭けであり、ウェブサイトの構築方法を変える可能性がある。

Stork.AI
Hero image for: MDNがReactを捨てた。彼らが代わりに使ったものとは。
💡

要約 / ポイント

ウェブで最も信頼されているドキュメントサイトが、React製のフロントエンドをすべて捨てた。彼らの新しいスタックは、ネイティブブラウザ技術への根本的な賭けであり、ウェブサイトの構築方法を変える可能性がある。

Reactが最大の擁護者を失った日

長年にわたり、ウェブ開発者はオープンウェブプラットフォームの揺るぎないバイブルとして、MDN Web Docs Web Docsに依拠してきました。それは単なるドキュメントサイトではなく、ベストプラクティスを指示し、標準を定義し、業界全体の無数のアーキテクチャ上の決定を導く決定的な権威として存在しています。したがって、その技術的選択は比類のない重みを持って響き渡り、インターネット向けに構築する方法のまさに基盤における変化を示唆しています。

その影響力は、この発表をまさに地殻変動のような出来事にしました。MDN Web Docs Web Docsが公式にReactを放棄したのです。これは静かな非推奨化や小規模なリファクタリングではありませんでした。それは、そのフロントエンド全体、Yariを動かしていたフレームワークの全面的な拒絶でした。Yariは「crazy webpack config」を持ち、`dangerouslySetInnerHTML`にさえ依存していた、Create React AppからイジェクトされたReact SPAでした。この動きは開発者コミュニティに衝撃を与え、まるで大手クラウドプロバイダーが突然その主力データベースのサポートを打ち切ったかのようでした。

この決定は単なる企業の再構築を超え、ウェブプラットフォーム自体の将来の方向性に関する深い声明です。HTML、CSS、JavaScriptをドキュメント化するまさにその存在であるMDN Web Docs Web Docsは、今やこれらの本質的な技術を使った構築を擁護しています。彼らはフロントエンド全体をゼロから再構築し、Litとカスタムサーバーコンポーネントを用いたWeb Componentsを採用しました。これは、以前のReactベースのSingle Page Applicationとは対照的です。

MDN Web Docs Web Docsは、あらゆるものにSPAという主流のトレンドから大胆かつ意図的に離れました。彼らの新しいアーキテクチャは、カスタム要素をコンテンツに直接統合し、ラッパーの必要性を排除し、未使用のJavaScriptを削減しています。このリーンで標準に準拠した開発へのコミットメントは、メインサイトのドロップダウンなどの機能に表れています。これは現在、JavaScriptがロードされる前に完全にCSSで動作し、その後段階的に機能が強化されます。開発環境の起動時間は2分から2秒に激減し、彼らの新しい高性能なアプローチの具体的な利点を示しています。

Yariの内部:MDNが排除せざるを得なかった「クレイジーな」スタック

イラスト:Yariの内部:MDNが排除せざるを得なかった「クレイジーな」スタック
イラスト:Yariの内部:MDNが排除せざるを得なかった「クレイジーな」スタック

MDN Web Docs Web Docsはかつて、そのフロントエンドとしてYariというReactベースのSingle Page Application (SPA) に依存していました。これは単純なReactの実装ではありませんでした。チームはYariをCreate React Appからイジェクトしており、これはカスタムで非常に複雑な構成への深い傾倒を示していました。イジェクトするということは、Create React Appの管理されたシンプルさを捨てて、より詳細な制御を得ることを意味し、この選択はしばしば時間の経過とともに大きなメンテナンス負担につながります。

Yariの増大する技術的負債の中心にあったのは、その「crazy webpack config」でした。この複雑な設定は、長年のカスタマイズ、パッチ適用、回避策の証であり、開発者の速度とビルド効率を著しく妨げていました。広範な設定はデバッグと更新を悪夢にし、遅く脆い開発体験を生み出しました。開発者は苦痛なほど長い待ち時間に直面し、開発環境の起動時間は苦痛な2分にまで膨れ上がっていました。これは、進化するウェブ標準の迅速な反復と包括的なドキュメント作成に焦点を当てたプロジェクトにとって、大きな足かせでした。

複雑さを増し、スタック本来のぎこちなさを露呈するように、Yariはコンテンツをレンダリングするために頻繁に`dangerouslySetInnerHTML`を使用していました。主要な目標が信頼できる情報を安全に提示することであるドキュメントサイトにとって、この慣行は重大なセキュリティリスクを伴い、クロスサイトスクリプティング(XSS)の脆弱性への道を開きました。また、本質的に扱いにくいと感じられ、手動でのコンテンツサニタイズを必要とし、Reactの宣言型レンダリングモデルを迂回していました。これは、チームが行った困難な妥協の明確な指標でした。

最終的に、Yariは根本的に誤用された強力なツールでした。複雑な状態管理を伴う高度にインタラクティブで動的なアプリケーション向けに設計された重いSPAは、MDN Web Docsの核となるミッション、つまり、ほとんど静的で標準に準拠したドキュメントを提供することには不向きであることが判明しました。このスタックは、大量の未使用のJavaScriptをすべてのページロードで送信し、ページのレンダリング速度の低下と非効率なユーザーエクスペリエンスの一因となっていました。このアーキテクチャは、MDN Web Docs自体が提唱するウェブパフォーマンスの原則と直接矛盾しており、チームを抜本的な見直しへと駆り立てた重大な不一致でした。

ネイティブブラウザ技術への抜本的な賭け

MDN Web Docsのフロントエンド再構築は、抜本的な哲学に基づいていました。それは、プラットフォームの上に構築するのではなく、プラットフォーム*と共に*構築するというものです。彼らは従来のフレームワークの抽象化レイヤーを意識的に拒否し、ネイティブブラウザの機能を直接採用しました。これは、Web Componentsへの全面的な転換を意味し、具体的には実装のためにLitを活用しました。

Web Componentsは、カスタムで再利用可能、かつカプセル化されたHTMLタグを作成するための強力なウェブ標準のスイートを提供します。その利点は多大です。Shadow DOMによる真のカプセル化は、スタイルやスクリプトの競合を防ぎ、フレームワークに依存しない再利用性を提供し、多様なフロントエンド環境間でのシームレスな相互運用性を保証します。このアプローチにより、コンポーネントはコンテンツ内に直接存在でき、ラッパーの複雑さを排除し、未使用のJavaScriptの送信をなくします。

この戦略的な転換は、ドキュメントサイトの将来性確保を優先します。Custom Elements、Shadow DOM、HTML Templatesといった基盤となるウェブ標準に依拠することで、MDN Web Docsは、単一のJavaScriptフレームワークをはるかに超える寿命を持つテクノロジーに投資しました。標準はゆっくりと予測可能に進化し、長期的な安定性を確保し、陳腐化のリスクを低減します。

これは、フレームワークが主流の世界で蔓延している急速な変化とエコシステムロックインとは対照的です。フレームワークはしばしば開発パターンを規定し、頻繁に破壊的な変更を導入し、絶え間ないリファクタリングと依存関係の更新を強要します。MDN Web Docsはこのサイクルを明確に回避し、一時的なトレンドよりも安定性を選択しました。

Litで構築されたWeb Componentsとカスタムサーバーコンポーネントを特徴とする新しいスタックは、具体的なパフォーマンス向上をもたらします。開発環境の起動時間は、苦痛な2分からわずか2秒に激減しました。このリーンなアーキテクチャは、ページが必要とする正確なCSSとJavaScriptのみがロードされることを保証し、送信されるコードを劇的に削減し、初期ページロード時間を向上させます。この変革の技術的な詳細についてさらに深く知りたい読者は、MDN Web Docsの新しいフロントエンドの舞台裏 - MDN Web Docsを参照してください。

Litのご紹介:アンチフレームワークの強力な存在

「React」を捨てたことで、MDN Web Docsはプラットフォーム上で構築するだけでなく、プラットフォームと共に構築するという哲学を受け入れました。この抜本的な転換は、高速で軽量なWeb Componentsを構築するためのシンプルなライブラリであるLitという理想的なパートナーを見つけました。Litは広範なフレームワークではなく、焦点を絞ったツールであり、アプリケーション全体のアーキテクチャを指示することなく、ネイティブなWeb Componentsを楽しく扱えるようにするのに十分な抽象化を提供します。

Litの魅力は、キロバイト単位で測定されることが多い最小限のフットプリントと、卓越したランタイムパフォーマンスにあります。直感的なデコレーターと宣言型レンダリングにより、リアクティブなテンプレート化と状態管理を簡素化し、ネイティブブラウザAPIの粗い部分を優雅に滑らかにする開発者フレンドリーなAPIを提供します。このアプローチにより、コンポーネントは驚くほど軽量で高速であり、Web標準に本質的に準拠しています。

重要なことに、Litはカスタム要素をHTML内に直接配置できるようにし、煩わしいラッパーコンポーネントや複雑なレンダリングツリーの必要性を排除します。これにより、ボイラープレートコードが大幅に削減され、コンポーネントが真にネイティブであり、標準のHTML要素とシームレスに共存できるようになります。MDN Web Docsの以前のReact SPAであるYari(Create React Appから排出されたもの)は、コンテンツを挿入するために「crazy webpack config」や`dangerouslySetInnerHTML`に頼ることが多く、その複雑な構造内で動的要素を統合する際の大きな摩擦を示していました。

LitはMDN Web Docsにとって実用的な中間点を提供し、生のブラウザAPIと本格的なフレームワークの間のバランスを取りました。バニラJavaScriptよりもはるかに多くの構造と保守性を提供しながらも、Reactのオーバーヘッドと意見のほんの一部しか持ちませんでした。これにより、チームは大規模で複雑な依存関係ツリーの負担なしに、最新のWeb標準の力を活用することができました。その結果、開発環境の起動時間を2分からわずか2秒に短縮するだけでなく、将来の開発にとっても信じられないほど直感的であり、オープンなWebプラットフォームを文書化し具現化するという彼らの使命に完全に合致するフロントエンドスタックが実現しました。

MDNの秘密兵器:自社開発のServer Components

イラスト:MDNの秘密兵器:自社開発のServer Components
イラスト:MDNの秘密兵器:自社開発のServer Components

MDN Web Docsは独自のサーバーコンポーネントを開発しました。これは、React Server Componentsが広く注目されるずっと前から、業界のサーバー駆動型UIへの移行を予見した先見の明のある動きでした。この独自のアーキテクチャは極限の効率性を目指し、すべてのページが超高速なユーザーエクスペリエンスのために必要不可欠なコードのみを配信することを保証します。チームはクライアントサイドのオーバーヘッドを最小限に抑えることを優先しました。これは、以前のCreate React AppベースのYariフロントエンドに関連する肥大化への直接的な対応です。

これらのカスタムサーバーコンポーネントは、Litコンポーネントをサーバー上で直接HTMLにレンダリングします。このプロセスにより、クライアントのワークロードが大幅に削減されます。NodeJSを利用して、MDN Web DocsのバックエンドはLitコードを処理し、インタラクティブなWeb Componentsがブラウザに到達する前に静的なHTML文字列に変換します。この堅牢なプリレンダリング機能により、クライアントサイドのレンダリング遅延が解消され、完全に形成されたコンテンツが即座に配信され、従来のクライアントサイドSPAの複雑さを回避します。

重要なことに、MDN Web Docsは、まだ広く採用されつつある強力なWebプラットフォーム機能であるDeclarative Shadow DOMを活用しています。このテクノロジーは、コンポーネントのシャドウDOMと関連するスタイルを、ロード後にJavaScriptで構築するのではなく、初期のHTMLペイロード内に直接埋め込みます。Declarative Shadow DOMをサポートするブラウザは、HTMLが到着した瞬間に、JavaScriptの1行も解析または実行を待つことなく、コンポーネントのカプセル化された構造とスタイルを即座にレンダリングできます。これにより、重要な視覚的ブーストが提供されます。

この革新的なアプローチにより、ユーザーはHTMLが到着した瞬間に完全にスタイル設定された機能的なコンポーネントを目にすることができ、体感パフォーマンスが劇的に向上し、累積レイアウトシフトが削減されます。ページに*実際に存在する*コンポーネントをハイドレートし、インタラクティブ性を追加するために必要なJavaScriptのみがダウンロードされます。特定のページにないコンポーネントからの未使用のJavaScriptはクライアントに到達することはなく、すべてのルートで潜在的に不要なコードの大きなバンドルを送信していた古いYari SPAとは対照的です。

MDN Web Docsのサーバーコンポーネントは、信じられないほど軽量で最適化されたペイロードを提供し、膨大なドキュメントライブラリの初期ロード時間と帯域幅消費を劇的に削減します。サーバーサイドレンダリングへのこの戦略的な投資は、ネイティブブラウザ機能と相まって、プラットフォームの上に構築するだけでなく、プラットフォームと共に構築するという深いコミットメントを示しています。その結果、ウェブ標準を説明するだけでなく、それが提唱するパフォーマンスと効率性の標準そのものを体現し、魅力的な代替手段を提供するドキュメントサイトが誕生しました。

2分から2秒へ:現実世界への影響

MDN Web Docsのフロントエンドアーキテクチャの変革は、開発者の生産性に最も劇的な影響をもたらしました。かつてエンジニアがローカル開発環境の起動に2分以上待っていたのに対し、新しいスタックはわずか2秒で起動します。この驚異的な起動時間の98%削減は、開発ワークフローを根本的に再構築し、コンパイルキューの代わりに機能開発やバグ修正に数え切れないほどの時間を解放します。

この新たな効率性は、内部開発サイクルをはるかに超えて、ドキュメントにアクセスするすべてのユーザーに直接利益をもたらします。訪問者は、ページの読み込みが大幅に高速化され、消費データが少なくなり、全体的に非常に軽快なユーザーエクスペリエンスを享受できるようになりました。このアーキテクチャはパフォーマンスを優先し、MDN Web Docsが低速なネットワーク接続やリソースに制約のあるデバイスでもアクセス可能で応答性を維持できるようにすることで、包括的なウェブを体現しています。

メインサイトのドロップダウンメニューを考えてみましょう。これはこのパフォーマンス優先の哲学の典型的な例です。現在、JavaScriptが読み込まれる前に完全にCSSで機能し、必要なスクリプトが利用可能になると段階的に機能が強化されます。このネイティブファーストのアプローチは、即座のインタラクティブ性と応答性を提供し、重いフレームワークを上に重ねるのではなく、ウェブプラットフォームで構築することの力を示しています。

これらの目覚ましい成果は、JavaScriptのペイロードを劇的に削減し、ブラウザネイティブ機能を完全に採用するというアーキテクチャ上の決定から直接もたらされています。重いReact Single Page Application (SPA)のオーバーヘッドを排除し、Web Componentsを戦略的に使用することで、不要な複雑さが取り除かれました。Litのようなライブラリはこれらのコンポーネントに軽量な基盤を提供し、MDN Web Docs独自のサーバーコンポーネントは、ページが必要とする正確なCSSとJavaScriptのみがクライアントに到達することを保証します。

最終的に、この変化はMDN Web Docsが文書化しているウェブ標準そのものへの深いコミットメントを表しています。複雑でイジェクトされたCreate React Appから、ネイティブブラウザ機能に基づいて構築された合理化されたスタックへの移行は、パフォーマンスを大幅に向上させただけでなく、影響力のあるウェブプラットフォームがどのように運用できるかについての新しいベンチマークを設定し、JavaScriptが少ないほど速度が向上することが多いことを証明しています。

プログレッシブエンハンスメント:JavaScriptがオプションの場合

MDN Web Docs の新しいスタックは、すべてのユーザーに堅牢で機能的なベースラインを優先する基本的な原則であるProgressive Enhancementを採用しています。このアプローチは、堅牢なHTMLとCSSを介して提供されるコアコンテンツと機能から始まり、JavaScriptはオプションの強化としてのみ重ねられます。スクリプトが失敗したり、ブロックされたり、まだ読み込まれていなかったりしても、サイトは完全に利用可能です。

サイトの主要なナビゲーションドロップダウン、つまり重要なインターフェース要素を考えてみましょう。これはCSSのみを使用して完全に動作し、JavaScriptを一切使用せずにユーザーの操作に応答します。必要なJavaScriptが読み込まれて初めて、改善されたキーボードナビゲーションや動的な状態管理などの追加の機能強化が施されます。これにより、多様なネットワーク条件下でも即座に利用可能で一貫したエクスペリエンスが保証されます。

このアーキテクチャの選択は、大きな利点をもたらします。強化されたresilience、幅広いアクセシビリティ、そして劇的に高速なperceived performanceです。低速な接続や古いデバイスを使用しているユーザーでも、完全に機能するサイトにアクセスでき、壊れたインターフェースに遭遇することはありません。コアコンテンツとナビゲーションは常に利用可能であり、堅牢な基盤を提供します。

このような戦略は、多くの現代的なSingle Page Application (SPA)アーキテクチャとは大きく対照的です。多くの場合、SPAはほぼ空白のページを提供し、コンテンツが表示されたりインタラクティブになったりする前に、大きなJavaScriptバンドルをダウンロード、解析、実行する必要があります。これは、ユーザーにとって重大な障害点と大幅な遅延を引き起こします。

MDN Web DocsのProgressive Enhancementへのコミットメントは、その哲学「プラットフォームの上に乗るだけでなく、プラットフォームと共に構築する」を強調しています。ネイティブブラウザの機能を最初に活用することで、チームはウェブ標準の決定的な情報源にアクセスするすべての人にとって、本質的に堅牢で、アクセスしやすく、パフォーマンスの高いウェブエクスペリエンスを提供しました。

コード以上のもの:UIの全面的な刷新

イラスト:コード以上のもの:UIの全面的な刷新
イラスト:コード以上のもの:UIの全面的な刷新

根本的なアーキテクチャの変更を超えて、MDN Web Docsは劇的なユーザーインターフェースの刷新も発表しました。これは単なるバックエンドコードの書き換えではなく、開発者がウェブの最も重要なドキュメントとどのようにやり取りするかを完全に再考したものです。新しいフロントエンドは、洗練された直感的なエクスペリエンスを提供し、現代のウェブ標準とユーザーファーストのアプローチへの根本的なコミットメントを直接反映しています。

訪問者は、プラットフォーム全体でよりクリーンで一貫した美学にすぐに気づきました。チームはタイポグラフィを細心の注意を払って洗練し、散文とコード例の両方に慎重に選択されたフォントで可読性を高め、長文記事の疲労を軽減しました。新しい専用のcode fontは、構文の判読性を劇的に向上させました。これは、プログラミングと技術的な正確さに焦点を当てたサイトにとって重要な詳細です。

特定のUI要素は大きな注目を集め、日常のインタラクションを変革しました。MDN Web Docsは、古いアセットをスケーラブルで一貫性のあるセットに置き換え、視覚的な明瞭さを向上させる鮮明なLucide iconsに移行しました。検索エクスペリエンスは強力な再設計が行われ、ドキュメントの発見を効率化する、より直感的で機能豊富なモーダルが導入されました。これは多くの場合、ユーザーにとって最初のインタラクションポイントです。トップナビゲーションでさえも包括的な刷新が行われ、重要なコンテンツへのより明確な経路が提供されました。

重要なことに、Litで構築された新しいコンポーネントベースのアーキテクチャが、これらの視覚的な強化を直接的に促進しました。Litの軽量なWebコンポーネントを採用することで、MDN Web Docsは一貫性のあるデザインシステムを確立し、何十万ものページにわたる一貫性を維持しながら、迅速な開発サイクルを確保することがはるかに容易になりました。このモジュラーアプローチにより、UI要素は再利用可能で、パフォーマンスが高く、一貫したスタイルが適用され、基盤となる技術力に見合うユーザーエクスペリエンス全体が向上しました。

これはSPA時代の終焉を告げるものなのか?

MDN Web Docsの抜本的な転換は、開発者の間で必然的に一つの疑問を投げかけます。これはReactの優位性の終焉、あるいはシングルページアプリケーション(SPA)時代そのものの終焉を告げるものなのでしょうか?答えは微妙であり、陳腐化の決定的な宣言ではありません。Reactは依然として強力なツールであり、リッチなクライアントサイドの状態管理が最重要となる、高度にインタラクティブで複雑なアプリケーションには不可欠です。

しかし、MDN Web Docsは基本的にコンテンツ配信プラットフォームとして機能します。その主な機能は、複雑なユーザーインタラクションを必要とする完全なSPAを管理することではなく、ドキュメントを効率的に提供することです。以前のYariスタック、つまりイジェクトされたCreate React Appは、「クレイジーなwebpack config」に悩まされ、コンテンツを統合するために`dangerouslySetInnerHTML`さえ必要とする「過剰な」ソリューションとなっていました。MDN Web Docsは、従来のSPAに固有の重いJavaScriptバンドルやクライアントサイドルーティングのオーバーヘッドを単純に必要としませんでした。

MDN Web Docsによるこの動きは、「SPAがデフォルト」という考え方から離れる、より広範で加速する業界トレンドを反映しています。開発者は、特定のユースケースに合わせた、より繊細なアーキテクチャソリューションをますます求めています。例としては、次のようなフレームワークやライブラリがあります。 - Astro - Qwik - 最新のサーバーサイドレンダリング(SSR)フレームワーク

これらの新しいソリューションは、部分的なハイドレーションアイランドアーキテクチャといった概念を提唱し、インタラクティブなコンポーネントに必要なJavaScriptのみを配信します。これらは初期ページロードパフォーマンスを優先し、サーバーサイドレンダリングを活用して高速でコンテンツ豊富なベースラインを提供します。この哲学は、Web ComponentsにLitを使用し、カスタムサーバーコンポーネントを使用してページが必要とする正確なCSSとJavaScriptのみをロードするMDN Web Docsの新しいスタックと完全に一致しています。

フロントエンド開発は成熟の新たな段階に入り、普遍的なフレームワークからターゲットを絞った効率性へと焦点を移しています。あらゆるプロジェクトで最新の流行フレームワークを盲目的に採用する時代は終わりつつあります。代わりに、エコシステムは現在、実世界のパフォーマンス指標と適合性に基づいた実用的な選択を重視し、ツールに対するより慎重なアプローチを求めています。

MDN Web Docsの劇的な改善 — 開発環境の起動が2分以上からわずか2秒に激減したこと — は、この変化を強調しています。彼らの決定は、プラットフォームで構築し、効率性を優先し、プログレッシブエンハンスメントを採用することが、コンテンツファーストのエクスペリエンスにおいてモノリシックなクライアントサイドフレームワークに勝る未来を裏付けています。これはReactの終焉ではなく、より思慮深く、パフォーマンスの高いフロントエンドの展望への明確なシグナルです。

MDNの賭けがあなたの次のプロジェクトに意味すること

MDN Web DocsのReactからの劇的な転換は、次のウェブプロジェクトを計画するあらゆるチームにとってのマスタークラスとなります。開発者と技術リーダーは、フロントエンドアーキテクチャに関する長年の仮定を今や批判的に再評価しなければなりません。これは単にMDN Web Docsの物語ではなく、不必要な複雑さなしに効率的で回復力のあるウェブ体験を構築するための強力な青写真です。

まず、サイト全体にわたるフルクライアントサイドフレームワークの実際の必要性を精査してください。MDN Web Docsの以前のYariスタック(Create React Appから排出されたもの)は、複雑なwebpack設定の負担となり、コンテンツをレンダリングするために`dangerouslySetInnerHTML`さえ必要としました。このレベルのフレームワークのオーバーヘッドは、コンテンツ主導型サイトではしばしば収益逓減をもたらし、開発者の時間を大幅に消費し、未使用のJavaScriptをメガバイト単位で出荷することになります。すべてのページにフルSPAが本当に不可欠かどうかを評価してください。

次に、Web Componentsを見過ごすのをやめましょう。これらは成熟した強力なプラットフォームプリミティブであり、JavaScriptフレームワークの絶え間ない変化から脱却するための堅牢な道を提供します。MDN Web Docsは、コンテンツ内に直接存在するカスタム要素を構築するためにLitを採用し、ラッパーコンポーネントの必要性を排除し、出荷されるコードを大幅に削減しました。このアプローチは、永続的な安定性、卓越したパフォーマンス、そしてウェブ標準に直接基づいた将来性のある基盤を提供します。

第三に、堅牢で高速なウェブ体験を構築するための基本的な原則として、プログレッシブエンハンスメントを再評価しましょう。MDN Web Docsの新しいスタックはこれを典型的に示しており、メインサイトのドロップダウンのようなコアUI要素は、JavaScriptがロードされる前にCSSだけで機能します。エンハンスメントを重ねることで、ネットワークの状態やブラウザの機能に関係なく、すべてのユーザーに堅固でアクセスしやすいベースラインが確保され、JavaScriptは依存関係ではなくオプションのレイヤーとなります。

次のプロジェクトのアーキテクチャを決定する際には、アプリケーションの性質を考慮してください。複雑な状態管理と頻繁なクライアントサイド更新を必要とする、高度にインタラクティブでデータ集約型のウェブアプリケーション(ダッシュボードやリアルタイムエディタなど)の場合、ReactのようなフルSPAは依然として強力な利点を提供します。しかし、ほとんどのコンテンツ量の多いウェブサイト、ドキュメントポータル、またはマーケティングサイトでは、MDN Web Docsは、サーバーレンダリングされたHTMLとターゲットを絞ったJavaScriptを使用した、より軽量なコンポーネントベースのアプローチの深い利点を示しています。この戦略は、不要なクライアントサイドの複雑さよりも、初期ページロード速度、回復力、および長期的な保守性を優先します。開発環境の起動時間が2分以上からわずか2秒に急落したことは、この影響を裏付けています。

よくある質問

MDNはなぜReactフロントエンドを置き換えたのですか?

MDNは、技術的負債を解消し、パフォーマンスを向上させ、自身のサイトを文書化しているウェブ標準に合わせるために、Yariと名付けられたReact SPAを置き換えました。古いスタックは複雑な設定を持ち、コンテンツ量の多いサイトには不要なJavaScriptを出荷していました。

MDNの新しい技術スタックは何ですか?

MDNの新しいスタックは、Litライブラリを使用したネイティブのWeb Components上に構築されています。また、カスタム構築されたサーバーコンポーネントも特徴であり、プログレッシブエンハンスメントを重視しており、JavaScriptがロードされる前にCSSだけでコア機能が動作するようにしています。

Litとは何ですか、なぜMDNはそれを選んだのですか?

Litは、高速なWeb Componentsを構築するための軽量ライブラリです。MDNがこれを選んだのは、シンプルで非常に高性能であり、ブラウザネイティブ技術を活用することで、より大規模なフロントエンドフレームワークのオーバーヘッドとロックインを回避できるためです。

新しいスタックはMDNのパフォーマンスをどのように改善しましたか?

新しいアーキテクチャは、ページが必要とする正確なCSSとJavaScriptのみをロードすることで、パフォーマンスを大幅に向上させました。また、開発環境の起動時間を2分以上からわずか2秒に短縮し、開発者エクスペリエンスも改善しました。

🚀もっと見る

AI最前線をキャッチアップ

Stork.AIが厳選したAIツール、エージェント、MCPサーバーをご覧ください。

すべての記事に戻る