本セッションの登壇者
セッション動画（YouTubeチャンネル登録もお願いします。）
今日はこんな感じのタイトルです。
事前提出時には(仮)とか銀の弾丸とか書いてしまったんですけれども、そんなものは例によってなかったのでみなさん忘れてください。
あほむです。
今日はLTということでスライドの情報量に対して、そんなに説明しないので資料はあとで読み返してくださいというスタイルでいきたいと思います。
Webフロントエンドの設計のスコープ
今回のWebフロントエンドの設計というのはこういうスコープです。
後ほど、これも確認いただければというところで、ではやっていきましょう。
SPA vs. MPA
タイトルにも入れたSPAとMPAということで、Web開発系の論壇でそうした対立構造を目にしたことがある人も少なくないのではないでしょうか。
いちおう、用語整理をします。
SPAは画面遷移時にHistory APIで制御する。そのうちNavigation APIにとって変わるかもしれませんけれども、主にJavaScriptで制御するイメージ。
MPAはトラディショナルなハイパーリンクですね。HTMLとHTMLがリンクでつながってるようなイメージです。
いろいろと議論が定期的に浮上してきますけれども、とくにSPAについてはコストが高いと、言われることがあります。個別の事情に強く依存するので、ここではあくまでそういう議論もあるよねくらいに認識してください。
一方、MPAはどうやって作るの? という話もあって、何を言ってるんだという方もおられるかもしれませんが、要はRuby on RailsとかLaravelとか、サーバがHTMLを生成してブラウザJSが味付け程度に載ってるよ的なトラディショナルなMVCのノウハウというものが、やっぱりNext.jsなどに慣れた層からすると、ちょっとギャップがあるのかなというところです。
私自身、両方経験はありますが、最近フォーム制御とかSPAぽい実装でやりたいっていうのは気持ちとしてわかります。
やっぱり象徴的な分類ではあるんですけれども、境界線はあいまいで、MPAの中に局所的なSPAが混ざることはありますし、ツール/フレームワークもSPAもMPAもさまざまな方法でサポートしています。
こういう事情から、二元論で設計を語るのはやはり難しいなと感じますし、諸条件をトータルで考えたら結果的にそうなった(SPA or MPAっぽい設計になった)みたいな温度感で考えるのが適切ではないかなと思う次第です。
現代Webの設計における関心事のおさらい
このような事情を踏まえつつ、SPAだろうとMPAだろうと設計上のポイントになる要素について、簡単におさらいします。
重要視される前提のポイントとして、ソフトウェアの重要な価値として性能が重要視されることが多いのではないでしょうか。
話をシンプルにするために、ほかの観点に関しては大胆に割愛させてもらっています。
大きい関心事として、HTMLの前後を速くすることということで、HTMLを読み込むまで、
いかに速く返却するか、HTMLの上に乗ったもろもろをいかに速く実行するかというところが主な焦点です。
そのための設計上の考えどころとしては3つあると思っていて、
- どこでHTMLを作るか
- キャッシュをどう効かせるか
- JavaScriptをどのくらい使うか
というところです。
サーバかエッジかHTMLについては、完成品を常に最速で返してくれるのがもっともシンプルな形だと思いますけれども、一方で何らかのSPAを採用する必要があるといった事情から、クライアントサイドでレンダリングしたほうが効率が良い場面もあります。
キャッシュについては生成したHTMLやその材料となるデータ、CSS、JavaScriptといったサブリソースたちを、それぞれどこでキャッシュをするかによっても設計が変わってきます。
最後に、どれぐらいJavaScriptを使う必要があるか。基本的に使えば使うほどファイルサイズが増えてダウンロードとか、その後の実行時の評価のためにHTMLの後ろ側が遅くなってくるわけですが、各種のパラメータにおける必要性を考えていければ順当に答えが出てくる部分かなとも思います。
ちょっと脱線したかったんですけど完全に時間が足りないので後でスライドをご覧ください。
いま紹介したような点を気にしながら、総合的にどのような手段を選び取っていくかというのが、現代的なフロントエンドの設計作業と言えるのではないでしょうか。
ちょうど良い力加減を見つける旅 - ケーススタディを眺めてみる
最後にケーススタディ的な話に移っていきます。
○Hotwire(参考リソース)
一番最初に紹介したHotwireというもので、Railsの7から搭載されているリアクティブなWebアプリをRailsで実現するための技術群という形になっています。
さっきトラディショナルなMVCと現代フロントエンドのギャップを指摘しましたけれども、伝統側のアンサーかなという気がします。
特徴的なのはHTMLの生成処理をサーバサイトにほぼ託しているところで、画面を部分的に更新する仕組みもありますけど、サーバサイドで作ったHTMLを差し込む感じになっていて、通じる世代向けにはものすごく賢くなったpjaxと言っても、そんなにイメージずれないかなと思います。
あとインタラクションを乗せるJavaScriptによる薄い層もありますけれども、全体としては"ザ・Rails"という感じなので、近年のWebフロントエンドにどっぷりな方には好まれなさそうですけど、仕組みとしては学びがあるかなと思います。
○メルカリWeb(参考リソース)
次に昨年リニューアルしたメルカリさんのWebです。
解説記事からの参照なので一部想像が混ざっていますが、さっき挙げた3つのポイントに照らし合わせると実質SPAなので、HTMLを作るのは主にクライアントサイド、キャッシュをする場所は(記事によれば)CDNに集約されていて、SPAなのでJavaScriptヘビーだと思われますが、いろいろな工夫をしているような気がします。
総じて想像し得る要件とか特性を考えるに「あ、わかる」という感じの落としどころじゃないかなという気がします。
○Shopify Hydrogen(参考リソース)
最後にReact Server Components、界隈では鳴り物入りなので関心の高い方はとっくにご存知だと思いますが、Shopifyが貴重な実践情報を記事にしています。
これがReactの覇権を延命させるに足るアンサーなのか、正直まだわかりませんが、ただ何をどのように解決しようとしてるのかを知るのは、Hotwire同様、現代のWebの設計におけるペインを理解する上で損がないのかなと思いました。
まとめ
では、LTらしく畳んでいきます。
まだ、SPA/MPAいってんのかという感覚の方は非常に正常だと思いますし、勘所を押さえた上でどうアレンジしているのかを俯瞰することで、理解が楽になるかなと思います。
以上です。ありがとうございました。
