ジュニア開発者向け SSR、SSG、SPA 完全ガイド-jsチュートリアル-php.cn

The Junior Developer

すべての開発ツール会社とチームは、ジュニア開発者がこれらの用語に精通していると想定しているようです。

私がコードを書き始めたとき、あちこちで目にしました。Nuxt は SSR フレームワークであり、SSG に Gatsby を使用でき、next.config.js で特定のフラグを設定すると SPA モードを有効にできます。

一体何?

最初のステップとして、用語集を示します。ただし、詳細を理解するのには役立ちません。

CSR = クライアントサイドレンダリング
SPA = シングルページアプリケーション
SSR = サーバーサイドレンダリング
SSG = 静的サイトの生成

次に、暗闇に光を当ててみましょう。

静的 Web サーバー

当初、Web サイトはサーバーからリクエストされた HTML ファイルでした。

あなたのブラウザはサーバーに「ねえ、その /about ページを渡してくれませんか?」と尋ねます。するとサーバーは about.html ファイルで応答します。あなたのブラウザは、このファイルを解析する方法を知っており、このような美しい Web サイトを表示しました。

このようなサーバーを 静的 Web サーバー と呼びます。開発者は HTML と CSS (および場合によっては少しの JS) を手書きで作成し、それをファイルとして保存し、フォルダーに配置すると、サーバーはリクエストに応じてそれを配信しました。ユーザー固有のコンテンツはなく、誰でもアクセスできる一般的な静的 (不変) コンテンツのみでした。

app.get('/about', async (_, res) => {
  const file = fs.readFileSync('./about.html').toString();
  res.set('Content-Type', 'text/html');
  res.status(200).send(file);
})

ログイン後にコピー

インタラクティブな Web アプリとリクエスト固有のコンテンツ

しかし、静的なウェブサイトは退屈です。

Web サイトと対話できれば、ユーザーにとってはさらに楽しいものになります。そこで開発者は、JS をタッチするだけで、ボタンをクリックしたり、ナビゲーションバーを展開したり、検索結果をフィルターしたりできるようにしました。ウェブはインタラクティブになりました。

これは、ユーザーが検索パラメーターとして送信した内容に応じて、/search-results.html ページに異なる要素が含まれることも意味します。

ユーザーは検索バーに入力して Enter キーを押し、検索パラメーターを含むリクエストをサーバーに送信します。次に、サーバーはデータベースから検索結果を取得し、有効な HTML に変換して、完全な /search-results.html ファイルを作成します。ユーザーは結果のファイルを応答として受け取りました。

(リクエスト固有の HTML の作成を簡素化するために、開発者はハンドルバーなどの HTML テンプレート言語を発明しました。)

app.get('/search-results', async (req, res) => {
  const searchParams = req.query.q;
  const results = await search(searchParams);

  let htmlList = '<ul>';
  for (const result of results) {
    htmlList += `<li>${result.title}</li>`;
  }
  htmlList += '</ul>';

  const template = fs.readFileSync('./search-results.html').toString();
  const fullPage = embedIntoTemplate(htmlList, template);

  res.set('Content-Type', 'text/html');
  res.status(200).send(fullPage);
});

ログイン後にコピー

「レンダリング」に関するちょっとした寄り道

私は長い間、レンダリングという用語が非常に紛らわしいと感じていました。

本来の意味では、レンダリングは、人間が処理可能な画像を作成するコンピューターを指します。たとえば、ビデオゲームの レンダリング は、ユーザーが魅力的な 3D エクスペリエンスとして利用できる、たとえば 1 秒あたり 60 枚の画像を作成するプロセスを指します。 サーバーサイドレンダリングについてはすでに聞いていたので、それがどのように機能するのか疑問に思いました。サーバーはどのようにして画像をユーザーに表示できるのでしょうか?

しかし、サーバー側またはクライアント側のレンダリングのコンテキストにおける「レンダリング」は別の意味であることがわかり、私もこれに気づくのが少し遅すぎました。

ブラウザのコンテキストでは、「レンダリング」は元の意味を保ちます。ブラウザは、ユーザーが見るための画像 (Web サイト) をレンダリングします。そのためには、最終結果がどうなるかの青写真が必要です。このブループリントは HTML および CSS ファイルの形式で提供されます。ブラウザはこれらのファイルを解釈し、そこからモデル表現であるドキュメントオブジェクトモデル (DOM) を派生し、レンダリングして操作できるようになります。

もう少し理解できるように、これを建物と建築物にマッピングしてみましょう。家の青写真 (HTML と CSS) があり、建築家はそれを机の上の小規模な物理モデル (DOM) に変換します。彼はそれを操作することができ、全員がその結果に同意すると、建設作業員はモデルを見て、それを実際の建物 (ユーザーが見るイメージ) に「レンダリング」します。

サーバーのコンテキストで「レンダリング」について話すときは、HTML や CSS ファイルの解析ではなく、作成について話します。これは、ブラウザが解釈するファイルを受信できるようにするために最初に行われます。

クライアントサイドレンダリングに移ります。「レンダリング」について話すときは、DOM (ブラウザが HTML および CSS ファイルを解釈して作成するモデル) を操作することを意味します。次に、ブラウザは DOM を人間が目に見える画像に変換します。

クライアント側のレンダリングとシングルページアプリケーション (SPA)

Facebook のようなプラットフォームの台頭により、開発者はより多くのより高速なインタラクティブ性を必要としました。

インタラクティブなウェブアプリでのボタンクリックの処理には時間がかかりました。HTML ファイルを作成し、ネットワーク経由で送信し、ユーザーのブラウザでそれを表示する必要がありました。

All that hassle while the browser could already manipulate the website without requesting anything from the server. It just needed the proper instructions — in the form of JavaScript.

So that's where devs placed their chips.

Large JavaScript files were written and sent to the users. If the user clicked on a button, the browser would insert an HTML component; if the user clicked a "show more" button below a post, the text would be expanded — without fetching anything.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body>
    <div id="root"></div>
    <script>
      document.addEventListener('DOMContentLoaded', () => {
        const root = document.getElementById('root');

        root.innerHTML = `
            <h1>Home</h1>
            <button>About</button>
        `;

        const btn = document.querySelector('button');
        btn.addEventListener('click', () => {
          root.innerHTML = `
            <h1>About</h1>
        `;
        });
      });
    </script>
  </body>
</html>

ログイン後にコピー

Though the code snippet suggests the opposite, developers didn't write vanilla JavaScript.

Ginormous web apps like Facebook had so much interactivity and duplicate components (such as the infamous Like-button) that writing plain JS became cumbersome. Developers needed tools that made it simpler to deal with all the rendering, so around 2010, frameworks like Ember.js, Backbone.js, and Angular.js were born.

Of them, Angular.js was the one that brought Single Page Applications (SPAs) into the mainstream.

An SPA is the same as Client-Side Rendering, but it is taken a step further. The conventional page navigation, where a click on a link would fetch and render another HTML document, was taken over by JavaScript. A click on a link would now fire a JS function that replaced the page's contents with other, already preloaded content.

For this to work properly, devs needed to bypass existing browser mechanisms.

For example, if you click on a