学習コストを最小限に抑えるために生まれたRemix
前置きが長くなりましたが、本記事の本題に入っていきましょう。SSRが得意なReact向けのフレームワークとして、Remixというものについて解説させてください。
Remixは、ReactによるWebサイト制作のやり方を他社の開発チームに対してトレーニングする会社である、React Training社を母体とする、Remixチームが開発したフレームワークです。
シングルページアプリケーションで画面遷移を行うためのライブラリ、React Routerを開発していた会社なので、名前を見たことがある人も多いかもしれません。
Remixが生まれた経緯
Remixチームはもともと他社への教育を事業にしていたため、学習コストについて注意を払う機会が多くありました。
一般的に、特定のフレームワークの中でしか役に立たない、そのフレームワークが廃れてしまったら使えなくなってしまう部分が多い技術を覚えるのは、中長期で見た場合の学習のコストパフォーマンスが悪いと言えます。
それならば、廃れる可能性が少ない、Webの標準仕様となったものを最大限に活用したフレームワークを作ろう、ということで生まれたのがRemixです。
Remixという哲学
Remixの使い方について解説する前に、Remixを採用する意義について話しておきましょう。Remixの公式ドキュメントには、Philosophyという、Remixを作るにあたっての思想・哲学について解説したページがあります。
Philosophyは、次の4つのポイントで成り立っています。
- サーバーとクライアントの協調に重点を置く（Server/Client Model）
- HTTP通信の扱いやHTMLの扱いはWeb標準に寄り添い連携する（Web Standards, HTTP, and HTML）
- プログレッシブエンハンスメント（Progressive Enhancement）
- 抽象化しすぎない（Don’t Over Abstract）
それぞれ、どういった話題なのかを解説します。
サーバーとクライアントの協調に重点を置く
SSRをリクエストの都度実行するとWebサーバーが詰まってしまうので、静的なファイルの割合が多いほど高速化できる、というのはWebサイト構築の定石のひとつでしたが、近年ではそれ以外のアプローチも現実的になってきました。 https://remix.runのWebサイトでは、エッジコンピューティングによる分散システムを構築することで、リクエストの都度SSRを行ってもパフォーマンス上の問題は起こりづらくなっているようです。
サーバーサイドの速度問題には、そういった分散システムのソリューションを扱ったり、お金をかけてサーバーのスペックを上げたりすることである程度の対策ができます。その一方で、ユーザーのネットワークはコントロールできません。
そうした状況でWebサイトを高速化したいのであれば、ユーザーのネットワークを通るデータ量を減らす必要があります。JavaScript、JSON、CSSを減らすことを意識しましょう。
シングルページアプリケーションのように、ブラウザ上のアプリケーションが主体となって通信を行い、表示すべきデータと表示しないデータをクライアント側で取捨選択する方式を取ると、ネットワークを通るデータは必然的に多くなってしまいます。それを避けるためには、サーバーでデータの取得と取捨選択を行い、絞った後のデータだけをHTMLに埋め込むSSRの手法を取るのが有効です。
Webフロントエンドの分野はクライアントにロジックを置く比重が大きくなりがちですが、サーバーにもしっかりとロジックの実行を任せて、ユーザーのネットワークを通るデータを可能な限り減らそう、というのがこのポリシーの要点です。
HTTP通信の扱いやHTMLの扱いはWeb標準に寄り添い連携する
Remixでは、近年のブラウザやHTMLの進化を素直に受け入れ、可能な限り活かす方向で作られています。
前述した学習コストの話題で少し触れましたが、Remixには「せっかく学習コストをかけるなら、Web標準を覚えることに労力を使ってほしい」という願いがあります。そのため、基本的なAPIについては、可能な限りRemix独自のAPIを用意せず、Web標準のAPIを採用しています。
例えばサーバーサイドでSSR中に外部へ通信を行いたい場合は、Web標準のWeb Fetch API、つまりfetch()関数が利用できます。サーバーの動作環境（Node.js、Deno、Cloudflare Workersなど）に関わらず、ブラウザと同じAPIのfetch()関数が利用できるのです。
Web標準のfetch()が使えるということは、Web標準のRequestやResponseもブラウザと同じように利用できるということです。また、URLSearchParamsやURLも整備されており、Remixの通信周りを覚えていくうちにいつの間にかWeb標準に詳しくなっている、という学習パスが実現しやすくなっています。
また、データを更新する際のAPIはHTMLの<form>を大きく変えずに実装していたり、リンク先のページを事前にダウンロードし始めたりする機能は、HTMLの<link rel="prefetch">で実現しています。
プログレッシブエンハンスメント
プログレッシブエンハンスメントとは、リッチな環境のユーザーには最高の体験を提供しつつ、そうでないユーザーにも基本的な機能は提供しよう、という設計哲学です。
Remixは、データの読み込みにはSSRの仕組みを採用しているため、HTMLとCSSをダウンロードした時点で画面を表示できます。また、データを更新する機能もHTMLの<form>を活用する形で組み込まれているため、こちらもHTMLだけで動作可能です。動作環境のJavaScriptサポートがない、もしくは弱くても機能するというのは、心強いですね。
もちろん、JavaScriptは動かないよりも動いたほうが、リッチな体験を提供できるようになっています。フォームによるデータの更新後に、画面内の一部分だけを再読み込みしたり、読み込み中のUIを表示したりといった細かい調整は、JavaScriptの動作時のみの挙動です。
こういった形で、より多くのユーザーへサービスを届けようとする仕組みが、Remixの重要な要素になっています。
抽象化しすぎない
Remixがもっとも大切にしていることは、より良いWebサイトが作れるようになることです。Webサイト制作に集中できるようにして、そこに少しだけRemixの手助けがあると便利になる、という状況が作れれば、Remixの存在感はさほどなくてもいい、という匙加減です。
Remix固有のAPIも、高度に抽象化された独自機能というよりは、Web標準の機能を少し便利に扱うための手助けとして用意している色合いが強く、やはりWeb標準のAPIを意識しやすいようになっています。
RemixでWebサイト制作をしていると、いつの間にかWeb標準に詳しくなる、という体験は、教育に携わってきたRemixチームらしい特性といえるでしょう。
Philosophyの最後は、この言葉で締められています。
"Get good at Remix, get good at the web.（Remixが上手になると、Webが上手になる）"
まとめ
今回は、Remixの思想・哲学と、その前提となるWebフロントエンド分野の課題について解説しました。次回からは実際にRemixを触ってみましょう。
