🧊

Transitional Apps by Rich Harris の要点まとめ

Jamstack Conf Session: Transitional Apps

先月のJamstack Conf 2021のトークより。

ほんとはもっと早くまとめたかったけど、仕事のアレがアレでな・・。

内容としては、ちょっと前に書いてたこの記事にも縁がある感じの内容かも。

なんでもSPAにするんじゃねぇ！という主張のその先 - console.lealog();

Webサイト・アプリをどう作るか？

  • という議論が最近よくある
    • 今も、今までも、きっとこれからも
  • Traditionalに作るか、Modernに作るかの2軸になってることが多い
  • つまりMPA vs SPA
    • この表現が正確かはさておき、それぞれの特徴をおさらい

MPA

  • リクエストに応じてサーバーでHTMLを作って返すクラシックな方法
    • サーバーはRailsやPHPなど
    • 前段にCDNがあるかもしれない
  • 基本的にクライアントはそれを表示するだけ
  • リンクを踏めばナビゲーションが起きて、またリクエストする
  • とてもシンプルで、長く使われてきた
  • しかしブラウザの進化もあり、ユーザーからの需要も高まってきた
  • そうなるとどうなるか
  • 初期表示のためにHTMLをレンダリングしていたサーバーはそのままに、その後の表示を更新をするため、JSを配信するようになった
    • 2つの言語が必要になった
    • コードベースも違うのに、密結合を余儀なくされた
    • 開発体験もよくないし、運用も難しい
  • そこで生み出されたのがSPA

SPA

  • サーバーは、空っぽのHTMLと、JSだけを返す
    • クライアントがそれを使ってすべての画面を表示する
  • リンクを踏んでもナビゲーションは起きない
    • クライアント内で完結して表示を更新する
    • アプリっぽくて好評
  • ただし問題もいろいろある
    • 大量のJSコードが必要
    • パフォーマンスの問題
    • 複雑さはバグを生む
    • 粗悪なアクセシビリティの問題
    • 必要なツールが多くて複雑
    • ブラウザの本来の挙動にそぐわない
  • 悪い例: インスタ
    • JSなしで動作しない
    • 巨大なJSファイルが必要
    • 戻るボタンも期待通りに動作しない
  • フォーカスやスクロールの管理の問題
    • フォーカス管理を放棄してるSPAがよくある
    • ページバックで画面をスクロールしなおすアレも微妙
  • ただ問題ばかりでもないし、SPAでしか実現できないこともある
    • メディアを再生しながらのページ回遊
    • クライアントでの状態の保持
    • アニメーションつきのページ遷移のUX
  • 3rdのJSも、SPAなら1度だけ評価すればいい
    • MPAだと全ページであの読み込みが必要になる・・

MPAとSPAのいいとこ取りをしたい

  • できる
  • MPA: 初期表示が早い
  • MPA: JSなしでも動作する（はず）
  • MPA: 本来のブラウザの動作に近い
  • MPA: 好きな言語で開発できる（いちおう）
  • SPA: コードベースが1つ
  • SPA: ナビゲーションが早い
  • SPA: 変わらない要素を永続化できる
  • SPA: クライアントでの状態
  • これを一挙に実現するものがあるとして、なんて名付ける？
    • TraditionalとModernのはざまで・・
  • Transitionalデザインという単語がある
    • 家具などのデザイン界隈で使われてる
  • Transitional Appsだ！

Transitional Appsに対する反論

  • まずは想定される反論に答えておきたい

1: そんなものは不要

  • SPAの利点は、JSなしでもできる
  • HTMLのカケラをサーバーで作って、それをWebSocketで配信する
  • アイデアとしては良いけど、ネットワークの速さに依存してしまう
  • 他にも気になる点はある
  • GitHubでも似たようなことをやってるが、バグが多い
    • closeしても消えない Issue(1)
    • クライアントでの選択状態がリセットされる
    • etc...
  • 気になって毎回手動でリロードしちゃう
    • （すごいわかる）
  • HTMLをプッシュするとこうなってしまう

2: ドキュメントサイトかアプリか

  • ドキュメントサイトを作るのに、アプリを作るツールは不要という論
  • 適切な道具を選ぼうという意味では同意できる
  • ただ、サイト or アプリの2軸の比較に意味はあるか？
  • 世の中にはそういう（サイト|アプリ）がたくさんある
    • 静的な技術ブログサイトをやってたけど、自分のPodcastとか再生しつつ回遊できるようにしたいなってなったとき、アプリとして作り直すか？

3: そもそもJavaScriptが嫌

  • という人たちも一定数いる
    • 文化の問題
    • 言語的に好きくないとか
  • エッジコンピューティングで解決って言うけど
  • 確かに好きな言語で書いたWASMも動く
  • けど、結局はJSがベターでしょうね
  • Transitional Appsは、サーバーでもクラウドでもエッジでもデプロイできる
    • もちろんクライアントでもServiceWorkerでもWebWorkerでも

4: JavaScript多すぎ

今度こそ、Transitional Apps

感想

という感じで、MPA or SPAではなくこれからは、Transitional Apps！

呼び方があるのは便利なのでそれでいいとして、あまり目新しい話はなかったな・・というのが個人的な感想。
弊社のクライアントワークではサーバーありきのソリューションに手を出しにくいせいもあって、いまいち追いきれてない世界線ってのもあるけど。

とはいえJSなし環境もちゃんと動くのが本来のWeb！みたいなところには共感できるし、理想のアーキテクチャを実現する方法は引き続き色々あるはずなので、要件にあわせてちゃんと選ぶことを諦めない姿勢が大事ってことかね〜。

そういえばRich氏、NYTを去りVercelに入ったんですって。SvelteのOSS活動をフルタイムでやってくそうな。おめでとうございます！