クライアントサイドフレームワークの概要

1996 年に JavaScript が登場すると、それまで静的なドキュメントで構成されていたウェブに、ところどころの操作の可能性と興奮が加わりました。 ウェブは単に ものを読む だけではなく、 何かをする ための場所になりました。 JavaScript の人気は着実に高まりました。 JavaScript を扱う開発者は、直面した問題を解決するためのツールを作成し、ライブラリーと呼ばれる再利用可能なパッケージにパッケージ化して、他のユーザーとソリューションを共有できるようにしました。このライブラリーの共有エコシステムは、ウェブの成長を形作るのに役立ちました。

現在、 JavaScript はウェブに不可欠な部分となり、すべてのウェブサイトの 98% で使用されており、ウェブは現代生活に不可欠な部分です。ユーザーは論文を書いたり、予算を管理したり、音楽をストリーミングしたり、映画を鑑賞したり、テキスト、音声、またはビデオチャットを使って遠距離の他のユーザーと瞬時にコミュニケーションしたりできます。ウェブを使用すると、これまでコンピューターにインストールされたネイティブアプリケーションでのみ可能であったことが実行できるようになります。これらの最新の複雑でインタラクティブなウェブサイトは、ウェブアプリケーションと呼ばれることがよくあります。

最新の JavaScript フレームワークの出現により、非常に動的でインタラクティブなアプリケーションの構築がはるかに簡単になりました。フレームワークは、ソフトウェアの構築方法についての意見を提供するライブラリーです。これらの意見により、アプリケーションの予測可能性と均一性が可能になります。予測可能性により、ソフトウェアを巨大なサイズに拡張しながらも保守可能になります。予測可能性と保守性は、ソフトウェアの健全性と寿命にとって不可欠です。

JavaScript フレームワークは、あなたが毎日使用するウェブサイトの多くを含む、現代のウェブ上の優れたソフトウェアの多くを強化しています。現在この記事を読んでいる MDN Web Docs は、React/ReactDOM フレームワークを使用してフロントエンドを強化します。

さまざまなフレームワークが存在しますが、現在「ビッグ 4 」は次のとおりであると考えられています。

Ember は、 SproutCore プロジェクトで開始された作業の継続として、2011 年 12 月に最初にリリースされました。これは古いフレームワークであり、React や Vue などの最新の代替フレームに比べてユーザー数は少ないですが、その安定性、コミュニティサポート、いくつかの賢いコーディング原則により、依然としてかなりの人気を誇っています。

Ember の学習を開始する (en-US)

Angular は、Google の Angular チームと個人および企業のコミュニティが主導するオープンソースのウェブアプリケーションフレームワークです。これは、 AngularJS を構築したのと同じチームによる完全な書き直しです。 Angular は 2016 年 9 月 14 日に正式にリリースされました。

Angular は、宣言型 HTML テンプレートを使用するコンポーネントベースのフレームワークです。ビルド時に、開発者に対して透過的に、フレームワークのコンパイラーがテンプレートを最適化された JavaScript 命令に変換します。 Angular は、JavaScript のスーパーセットである TypeScript を使用します。これについては、次の章でもう少し詳しく説明します。

Angular の学習を開始する

オリジナルの AngularJS プロジェクトに取り組み、そこから学んだエヴァン・ユーは、2014年に Vue をリリースしました。 Vue はビッグ 4 の中では最も歴史が浅いが、最近人気が急上昇しています。

Vue は、 AngularJS と同様に、独自のコードの一部で HTML を拡張します。それとは別に、主に最新の標準 JavaScript に依存しています。

Vue の学習を開始する (en-US)

Facebook は 2013 年に React をリリースしました。この時点で、Facebook はすでに React を使用して社内の問題の多くを解決していました。技術的には、 React 自体はフレームワークではありません。これは UI コンポーネントをレンダリングするためのライブラリーです。 React は、アプリケーションを作成するために他のライブラリーと組み合わせて使用されます。 React と React Native を使用すると、開発者はモバイルアプリケーションを作成できます。 React と ReactDOM を使用すると、ウェブアプリケーションなどを作成できます。

React と ReactDOM は一緒に使用されることが多いため、React は口語的に JavaScript フレームワークとして理解されています。このモジュールを読み進めるにつれて、その口語的な理解に基づいて作業していきます。

React は、 JSX として知られる HTML のような構文で JavaScript を拡張します。

React の学習を開始する

フレームワークの作成にインスピレーションを与えた環境について説明しましたが、実際には、開発者がフレームワークを作成する必要性を なぜ 感じたのかというと、そうではありません。その理由を探るには、まずソフトウェア開発の課題を検討する必要があります。

一般的な種類のアプリケーション、 To-Do リスト作成ツールを考えてみましょう。これについては、今後の章でさまざまなフレームワークを使用して実装する方法を見ていきます。このアプリケーションでは、ユーザーがタスクのリストの表示、新しいタスクの追加、タスクの削除などを実行できるようにする必要があります。そして、アプリケーションの基礎となるデータを確実に追跡および更新しながらこれを実行する必要があります。ソフトウェア開発では、この基礎となるデータは状態として知られています。

私達のそれぞれの目標は、理論的には単独では単純です。データを反復処理してレンダリングできます。オブジェクトに追加して新しいタスクを作成できます。識別子を使用してタスクを検索、編集、削除できます。アプリケーションではユーザーがこれら すべて をブラウザー経由で実行できるようにする必要があることを思い出すと、いくつかの課題が見え始めます。本当の問題は、アプリケーションの状態を変更するたびに、それに合わせて UI を更新する必要があるということです。

この問題の難しさは、To Do リストアプリの 1 つの機能、つまりタスクのリストのレンダリングだけを見て調べることができます。

HTML 要素を構築し、適切なタイミングでブラウザーにレンダリングするには、驚くほどの量のコードが必要です。状態が次のように構造化されたオブジェクトの配列であるとします。

const state = [
  {
    id: "todo-0",
    name: "Learn some frameworks!",
  },
];

それらのタスクの 1 つをユーザーにどのように表示すればよいでしょうか? 各タスクをリスト項目として表現したいとします。つまり、(順序なしリスト要素 <ul> 内の) HTML <li> 要素です。どうやって作るのでしょうか？それは次のようになります。

function buildTodoItemEl(id, name) {
  const item = document.createElement("li");
  const span = document.createElement("span");
  const textContent = document.createTextNode(name);

  span.appendChild(textContent);

  item.id = id;
  item.appendChild(span);
  item.appendChild(buildDeleteButtonEl(id));

  return item;
}

ここでは、 document.createElement() メソッドを使用して <li> を作成し、さらに数行のコードで必要なプロパティと子を作成しています。

前のスニペットの 10 行目は、別のビルド関数 buildDeleteButtonEl() を参照しています。これは、リスト項目要素を構築するために使用したパターンと同様のパターンに従います。

function buildDeleteButtonEl(id) {
  const button = document.createElement("button");
  const textContent = document.createTextNode("Delete");

  button.setAttribute("type", "button");
  button.appendChild(textContent);

  return button;
}

このボタンはまだ何も実行しませんが、削除機能の実装を決定すると後で実行されます。ページ上に項目をレンダリングするコードは次のようになります。

function renderTodoList() {
  const frag = document.createDocumentFragment();
  state.tasks.forEach((task) => {
    const item = buildTodoItemEl(task.id, task.name);
    frag.appendChild(item);
  });

  while (todoListEl.firstChild) {
    todoListEl.removeChild(todoListEl.firstChild);
  }
  todoListEl.appendChild(frag);
}

これで、UI 専用のコードが 30 行を はるかに 超えています。つまり、 DOM 内で 何かを レンダリングするためだけに、後でリスト項目のスタイルを設定するために使用できるクラスを追加する必要はありません。

DOM を直接操作して、この例のように要素の作り方、プロパティを変更する方法、要素を互いの内側に配置する方法、ページ上にそれらを表示する方法など DOM の仕組みについて多くのことを理解する必要があります。このコードは実際にユーザー操作を処理したり、タスクの追加や削除に対処したりするものはありません。これらの機能を追加する場合は、適切なタイミングで適切な方法で UI を更新することを忘れないでください。

JavaScript フレームワークは、この種の作業をはるかに簡単にするために作成されました。 JavaScript フレームワークは、より良い 開発者体験 を提供するために存在します。これらは JavaScript にまったく新しい機能をもたらすわけではありません。これらにより、JavaScript の機能に簡単にアクセスできるようになり、今日のウェブに合わせて構築できるようになります。

このセクションのコードサンプルの動作を確認したい場合は、 CodePen 上のアプリの動作バージョン をチェックアウトしてください。これにより、ユーザーは次の機能を追加したり、新しいタスクを削除します。

このセクションで使用される JavaScript について詳しくは、以下をご覧ください。

• document.createElement()
• document.createTextNode()
• document.createDocumentFragment()
• eventTarget.addEventListener()
• node.appendChild()
• node.removeChild()

すべての JavaScript フレームワークは、ユーザーインターフェイスをより 宣言的に 記述する方法を提供します。つまり、UI がどのように見えるべきかを記述するコードを作成でき、フレームワークはそれを舞台裏の DOM で実行します。

新しい DOM 要素を繰り返し構築する標準的な JavaScript のアプローチは、一見しただけでは理解するのが困難でした。対照的に、次のコードブロックは、 Vue を使用してタスクのリストを記述する方法を示しています。

<ul>
  <li v-for="task in tasks" v-bind:key="task.id">
    <span>{{task.name}}</span>
    <button type="button">Delete</button>
  </li>
</ul>

これだけです。このスニペットにより、約 32 行のコードが 6 行に減ります。 ここでの中括弧と v- 属性に馴染みがなくても大丈夫です。 Vue 固有の構文については、モジュールの後半で学習します。ここで理解すべきことは、このコードはそれが表す UI に似ているのに対し、 Vanilla Javascript コードはそうではないということです。

Vue のおかげで、 UI を構築するために独自の関数を作成する必要がなくなりました。フレームワークは、最適化された効率的な方法でそれを処理します。ここでの私たちの唯一の役割は、各項目がどのように見えるべきかを Vue に記述することでした。 Vue に精通している開発者は、プロジェクトに参加すると何が起こっているのかをすぐに理解できます。これは Vue だけではありません。フレームワークを使用すると、チームだけでなく個人の効率も向上します。

これと 似たようなこと を Vanilla Javascript でも実現できます。テンプレートリテラル文字列を使用すると、最終的な要素がどのようになるかを表す HTML の文字列を簡単に作成できます。これは、 To Do リストアプリケーションのような単純なものには便利なアイデアかもしれませんが、数千のデータレコードを管理し、ユーザーインターフェイスに同じ数の固有の要素をレンダリングする可能性がある大規模なアプリケーションでは維持できません。

フレームワークが提供する他の利点を見てみましょう。前にも述べたように、フレームワークの利点は Vanilla Javascript でも実現可能ですが、フレームワークを使うことで、これらの問題を自分で解決しなければならないという認知的な負荷をすべて取り除くことができます。

このモジュールに含まれるフレームワークはそれぞれ大規模で活発なコミュニティを持っているので、それぞれのフレームワークのエコシステムは開発者の経験を向上させるツールを提供します。これらのツールによって、テスト(アプリケーションがあるべきように動作することを保証する) や lint (コードがエラーフリーでスタイルが一貫していることを保証する)のようなものを簡単に追加できます。

ほとんどの主要なフレームワークは、開発者がユーザーインターフェイスのさまざまな部分を コンポーネント 、つまり相互に通信できる保守可能で再利用可能なコードの塊に抽象化することを推奨しています。特定のコンポーネントに関連するすべてのコードは 1 つのファイル (またはいくつかの特定のファイル)に保存できるため、開発者はそのコンポーネントに変更を加えるためにどこに行けばよいかを正確に知ることができます。 Vanilla Javascript アプリでは、これを効率的かつスケーラブルな方法で実現するには、独自の規則セットを作成する必要があります。多くの JavaScript 開発者は、自分のデバイスに任せると、 UI の一部に関連するすべてのコードが 1 つのファイル全体に、または別のファイル全体に分散されてしまう可能性があります。

ウェブの最も重要な機能は、ユーザーがあるページから別のページに移動できることです。ウェブは結局のところ、相互リンクされたドキュメントのネットワークです。このウェブサイト上のリンクをたどると、ブラウザーがサーバーと通信し、表示する新しいコンテンツを取得します。そうすると、アドレスバーの URL が変わります。この新しい URL を保存して、後でそのページに戻ったり、他のユーザーと共有して同じページを簡単に見つけたりすることができます。ブラウザーはナビゲーション履歴を記憶しており、前後に移動することもできます。これは サーバー側ルーティング と呼ばれます。

最新のウェブアプリケーションは通常、新しい HTML ファイルを取得してレンダリングしません。ユーザーをウェブ上の新しいアドレスに誘導することなく、単一の HTML シェルをロードし、その中の DOM (シングルページアプリ、または SPA: Single Page Aoolication と呼ばれます) を継続的に更新します。新しい疑似ウェブページは通常、 ビュー と呼ばれ、デフォルトではルーティングは行われません。

SPA が十分に複雑で、十分な独自のビューをレンダリングする場合、アプリケーションにルーティング機能を組み込むことが重要です。人々は、アプリケーション内の特定のページにリンクしたり、ナビゲーション履歴を前後に移動したりできることに慣れていますが、これらの標準的なウェブ機能が壊れるとエクスペリエンスが低下します。この方法でクライアントアプリケーションによってルーティングが処理される場合、それは適切にもクライアントサイドルーティングと呼ばれます。

JavaScript とブラウザーのネイティブ機能を使用してルーターを作成することは 可能 ですが、人気があり積極的に開発されているフレームワークには、ルーティングを開発プロセスのより直感的な部分にする付属ライブラリーがあります。

有能なウェブ開発者になるには、仕事に最適なツールを使用する必要があります。 JavaScript フレームワークはフロントエンドアプリケーションの開発を容易にしますが、すべての問題を解決する特効薬ではありません。このセクションでは、フレームワークを使用する際に考慮すべき点について説明します。フレームワークがまったく必要ない場合もあることを念頭に置いてください。フレームワークを目的だけで使用することのないように注意してください。

Vanilla Javascript と同様に、フレームワークは学習に時間がかかり、癖があります。プロジェクトにフレームワークを使用することを決定する前に、そのフレームワークが自分にとって不利になるのではなく、自分にとって役立つように、その機能を十分に学習する時間を確保し、チームメイトもそのフレームワークに慣れているかどうかを確認してください。

もしあなたのウェブ開発プロジェクトが数ページの個人的なポートフォリオで、それらのページにインタラクティブな機能がほとんどない、もしくは全くないのであれば、フレームワーク（とその JavaScript のすべて）は全く必要ないかもしれません。とはいえ、フレームワークは一枚岩ではないし、小規模なプロジェクトに適したものもある。 Smashing Magazine の記事で、 Sarah Drasner は、ウェブページの小さな部分をインタラクティブにするツールとして、Vue が jQuery を置き換えることができるということを書いています。

フレームワークを使用すると、舞台裏で DOM インタラクションを処理することで、より宣言的なコードを作成でき、場合によっては全体的にコードが 少なくなる 場合もあります。 この抽象化は開発者としてのエクスペリエンスに最適ですが、無料ではありません。作成した内容を DOM の変更に変換するには、フレームワークが独自のコードを実行する必要があり、その結果、最終的なソフトウェアのサイズが大きくなり、操作にかかる計算コストが高くなります。

追加のコードは避けられず、ツリーシェイキング(ビルドプロセス中にアプリで実際に使用されていないコードの削除)をサポートするフレームワークを使用すると、アプリケーションを小さく保つことができますが、これは依然として必要な要素です。特に携帯電話など、ネットワークやストレージに制約のあるデバイスでのアプリのパフォーマンスを考慮する際には、この点に留意してください。

フレームワークの抽象化は、 JavaScript だけでなく、ウェブの性質そのものとの関係にも影響します。ウェブ用にどのように構築しても、最終結果、つまりユーザーが最終的に対話するレイヤーは HTML です。アプリケーション全体を JavaScript で記述すると、 HTML とそのさまざまなタグの目的を見失い、セマンティックではなくアクセスできない HTML ドキュメントが作成される可能性があります。実際、 JavaScript に完全に依存し、 JavaScript なしでは機能しない脆弱なアプリケーションを作成することも可能です。

フレームワークが問題の原因ではありません。優先順位を間違えると、アプリケーションは壊れやすく、肥大化し、アクセスできなくなる可能性があります。ただし、フレームワークにより、開発者としての優先順位がさらに高まります。複雑なウェブアプリを作成することを優先する場合、それは簡単です。ただし、優先順位によってパフォーマンスとアクセシビリティが慎重に守られていない場合、フレームワークによって脆弱性、肥大化、アクセス不能性が増幅されてしまいます。フレームワークによって強化された現代の開発者の優先順位は、多くの場所でウェブの構造を逆転させています。 現在のウェブでは、堅牢なコンテンツ優先のドキュメントネットワークの代わりに、 JavaScript が優先され、ユーザーエクスペリエンスが最後に配置されることが多くなっています。

前のセクションで述べたことを踏まえて、アクセシビリティについてもう少し詳しく説明しましょう。ユーザーインターフェイスをアクセスしやすくするには、常にある程度の思考と努力が必要ですが、フレームワークによってそのプロセスが複雑になる場合があります。 ARIA ライブリージョン やフォーカス管理などのネイティブブラウザー機能にアクセスするには、多くの場合、高度なフレームワーク API を使用する必要があります。

場合によっては、フレームワークアプリケーションによって、従来のウェブサイトには存在しないアクセシビリティの障壁が生じることがあります。この最大の例は、前述したように、クライアント側のルーティングです。

従来の(サーバーサイド)ルーティングでは、ウェブをナビゲートすると予測可能な結果が得られます。ブラウザーはページの上部にフォーカスを設定することを認識し、支援技術がページのタイトルをアナウンスします。これらのことは、新しいページに移動するたびに発生します。

クライアント側ルーティングでは、ブラウザーは新しいウェブページを読み込まないため、フォーカスを自動的に調整したり、新しいページタイトルをアナウンスしたりする必要があることを認識しません。フレームワークの作成者は、これらの機能を再現する JavaScript の作成に膨大な時間と労力を費やしてきましたが、それでも、これほど完璧に実行できるフレームワークはありませんでした。

結論としては、 すべての ウェブプロジェクトの最初からアクセシビリティを考慮する必要がありますが、そうしないと、フレームワークを使用する抽象化されたコードベースで重大なアクセシビリティの問題が発生する可能性が高くなることに留意してください。

このモジュールで説明する各フレームワークは、ウェブアプリケーション開発に対して異なるアプローチを取ります。それぞれが定期的に改善されたり変化したりしており、それぞれに長所と短所があります。適切なフレームワークを選択することは、チームとプロジェクトに依存するプロセスであり、何があなたのニーズに合っているかを明らかにするために、あなた自身で調査する必要があります。とはいえ、選択肢をより効果的に調査するために、いくつかの質問を挙げてみました

1. フレームワークはどのブラウザーをサポートしていますか？
2. フレームワークではどのようなドメイン固有言語が使用されますか？
3. このフレームワークには強力なコミュニティがあり、優れたドキュメント(およびその他のサポート)が利用可能ですか？

このセクションの表は、各フレームワークが現在提供している ブラウザーのサポート と、ドメイン固有言語を一目でわかるようにまとめたものです。

大まかに言うと、ドメイン固有言語（DSL）は、ソフトウェア開発の特定の分野に関連するプログラミング言語です。フレームワークの文脈では、 DSL は JavaScript や HTML のバリエーションで、そのフレームワークでの開発を容易にします。重要なことは、どのフレームワークも特定の DSL を使うことを開発者に 要求 しませんが、ほとんどすべてのフレームワークが特定の DSL を念頭に置いて設計されているということです。フレームワークが推奨する DSL を使わないという選択は、そうでなければ開発者のエクスペリエンスを向上させる機能を逃してしまうことを意味します。

新しいプロジェクトを選択するときは、フレームワークのサポートマトリックスと DSL を真剣に検討する必要があります。ブラウザーのサポートが一致しないと、ユーザーの障害となる可能性があります。 DSL サポートが一致しないと、あなたとあなたのチームメイトにとって障害となる可能性があります。

コミュニティの規模はアクセスしやすい数字と直接相関しないため、これはおそらく測定するのが最も難しい指標です。プロジェクトの GitHub スターの数や週ごとの npm ダウンロードを確認して人気を知ることができますが、いくつかのフォーラムを検索したり、他の開発者に相談したりするのが最善の場合もあります。コミュニティの規模だけでなく、コミュニティがどれほど歓迎的で包括的であるか、利用可能なドキュメントがどれほど優れているかも重要です。

この問題については、私たちの言葉をそのまま鵜呑みにしないでください。ウェブ上では議論が行われています。ウィキメディア財団は最近、フロントエンドに Vue を使用することを選択し、フレームワークの採用に関するコメント要求( RFC )を投稿しました。 RFC の著者である Eric Gardner は、時間をかけてウィキメディアプロジェクトのニーズと、特定のフレームワークがチームにとって良い選択である理由を概説しました。この RFC は、フロントエンドフレームワークの使用を計画するときに自分で行うべき調査の優れた例として役立ちます。

JavaScript の現状調査アンケート は、 JavaScript 開発者からの有益なフィードバックを集めたものです。フレームワークの使用とフレームワークに対する開発者の感情の両方に関するデータなど、 JavaScript に関連する多くのトピックをカバーしています。現在、数年分のデータが入手可能であり、フレームワークの人気を把握することができます。

Vue チームは Vue を他の一般的なフレームワークと徹底的に比較しました。この比較には多少の偏りがあるかもしれません(彼らはそれを指摘しています)が、それでも貴重な情報源です。

ウェブ開発プロセスを迅速化するツールを探していて、プロジェクトで集中的なクライアントサイド JavaScript が必要ないことがわかっている場合は、ウェブを構築するための他のいくつかのソリューションのいずれかを利用できます。

• コンテンツ管理システム
• サーバーサイドレンダリング
• 静的サイトジェネレーター

コンテンツ管理システム (CMS: Content-management systems) は、ユーザーが自分で直接コードを書かずにウェブ用のコンテンツを作成できるツールのことです。大規模なプロジェクト、特にコーディング能力に乏しいコンテンツ・ライターからのインプットを必要とするプロジェクトや時間を節約したいプログラマーにとっては良いソリューションです。しかし CMS のセットアップにはかなりの時間を要し、 CMS を利用するということは、少なくともウェブサイトの最終的なアウトプットをコントロールする手段を放棄することを意味します。例えば、選択したCMSがデフォルトでアクセシブルなコンテンツを作成しない場合、これを改善するのは難しいことが多いです。

一般的な例としては、 Wordpress 、 Joomla 、 Drupal などがあります。

サーバーサイドレンダリング (SSR: Server-side rendering) は、単一ページアプリケーションをレンダリングするのが サーバー の仕事であるアプリケーションアーキテクチャです。これは、JavaScript アプリケーションを構築する最も一般的で最も簡単な方法である クライアントサイドレンダリング の逆です。サーバーサイドレンダリングは、レンダリングされた HTML ファイルをクライアントのデバイスに送信するだけなので、クライアントのデバイスでは簡単ですが、クライアント側でレンダリングされるアプリケーションに比べてセットアップが難しい場合があります。

このモジュールで説明されているフレームワークはすべて、クライアントサイドのレンダリングだけでなくサーバーサイドのレンダリングもサポートしています。 React については Next.js 、Vue については Nuxt.js(はい、わかりにくいです、いいえ、これらのプロジェクトは関係ありません!)、 Ember の場合は FastBoot、 Angular の場合は Angular Universal をチェックしてください。

静的サイトジェネレーターは、複数ページのウェブサイトのすべてのウェブページ(関連する CSS や JavaScript を含む)を動的に生成し、任意の数の場所に公開できるようにするプログラムです。公開ホストは例えば、 GitHub ページブランチ、 Netlify インスタンス、または選択したプライベートサーバーにすることができます。このアプローチには多くの利点があり、主にパフォーマンス(ユーザーのデバイスは JavaScript を使用してページを構築していません。すでに完成しています)とセキュリティ(静的ページは攻撃ベクトルが少ない)に関するものです。これらのサイトでは、必要に応じて JavaScript を引き続き利用できますが、 JavaScript に「依存」しているわけではありません。静的サイトジェネレーターは、他のツールと同様に学習に時間がかかるため、開発プロセスの障壁となる可能性があります。

静的サイトには、必要な数の固有のページを含めることができます。フレームワークを使用すると、クライアント側の JavaScript アプリケーションを迅速に作成できるようになりますが、静的サイトジェネレーターを使用すると、個別に作成する必要があった HTML ファイルを迅速に作成できます。フレームワークと同様、静的サイトジェネレーターを使用すると、開発者はウェブページの共通部分を定義するコンポーネントを作成し、それらのコンポーネントを組み合わせて最終ページを作成できます。静的サイトジェネレーターのコンテキストでは、これらのコンポーネントは テンプレート と呼ばれます。静的サイトジェネレーターによって構築されたウェブページは、フレームワークアプリケーションのホームとなることもあります。たとえば、静的に生成されたウェブサイトの特定のページで、ユーザーがそのページにアクセスしたときに React アプリケーションを起動したい場合は、それが可能です。

静的サイトジェネレーターはかなり昔から存在しており、最近のウェブの歴史の中で少しずつ復活を遂げています。 Hugo 、 Jekyll 、Eleventy および Gatsby などのいくつかの強力なオプションが利用可能になりました。

静的サイトジェネレーター全体について詳しく知りたい場合は、Tatiana Mac の Eleventy の初心者ガイドを参照してください。シリーズの最初の記事では、静的サイトジェネレーターとは何か、そしてそれがウェブコンテンツを公開する他の手段とどのように関連するのかについて説明します。

これで、フレームワークの紹介は終わりになります。まだコードを教えていませんが、そもそもフレームワークを使用する理由と、フレームワークの選択方法について有益な背景を提供できたことを願っています。 1 つ目は、もっと学びたい、夢中になってみたいという気持ちになっていただければ幸いです。

次の記事では、より低いレベルまで掘り下げて、フレームワークが提供する傾向にある特定の種類の機能と、フレームワークがなぜそのように機能するのかを見ていきます。

• Overview: クライアントサイドの JavaScript フレームワークを理解する
• 次のページ