- 一部の開発者は、SPAフレームワーク（React、AngularJS など）が高品質なアプリケーション開発に不可欠だと考えている
- しかし、SPA以前からMPAベースのアプリケーションは優れたユーザー体験を提供してきた
- 私はHTMXを活用してデータ中心のMPAベース観測プラットフォームの開発を試み、適切な最適化によりサーバーレンダリングMPAでも優れた性能とユーザー体験を提供できることを確認した
MPAに関する誤解と真実
誤解1: MPAはページ遷移時に遅い
- 問題: ブラウザがデフォルトではページ遷移のたびにJavaScriptとCSSを再ダウンロードするため
- 解決策:
- PJAX、Turbolinks、HTMX Boost のようなライブラリを使ってHTML bodyだけを置き換える
- サービスワーカーを活用してページキャッシュとリクエスト処理を改善できる
- 例: サービスワーカー適用時、DOMContentLoaded 時間が2.9秒から500msに短縮された
サービスワーカーの実装方法
sw.js ファイルを作成: キャッシュとネットワークリクエスト管理スクリプトを作成- キャッシュするファイル一覧を定義: HTML、CSS、JS など主要アセットを指定
- キャッシュ戦略を設定: 静的アセットを永続キャッシュするか、定期的に更新
誤解2: MPAはオフライン動作やネットワーク復旧時のリクエスト保存ができない
- サービスワーカーを使えば、オフライン状態でもアプリを動作させられる
- Workbox の活用:
- ネットワーク失敗時にリクエストをキャッシュし、最大24時間以内に再試行
- オフラインハンドラーを設定して、リクエスト時に代替コンテンツを提供
誤解3: MPAはページ遷移時に画面のちらつきが発生する
- 解決策:
- サービスワーカーとプリロードAPIで、アセットの準備ができるまで画面描画を遅らせる
- 2019年以降、ブラウザは同一ドメイン内の遷移をちらつきなく処理する
誤解4: MPAでは派手なページ遷移効果を実装できない
- SPAはページ遷移アニメーションで有名だが、ブラウザもこれをサポートし始めている
- Chrome 126 ではCSSだけでクロスドキュメント遷移アニメーションを実装できる
- デモリンク
誤解5: HTMXやMPAでは、すべてのユーザー操作がサーバーで処理される
- HTMXは一部の処理だけをサーバーで扱うよう設計されている
- 必要に応じて WebComponents やJavaScriptフレームワークでクライアント側のインタラクティブ機能を追加できる
- 特定のコンポーネントにだけSPA方式を適用することも可能
誤解6: DOM操作は遅い。だからReact/Virtual DOMの利用が必要
誤解7: 小さなインタラクティブ機能にもJavaScriptが必要
- 最新のブラウザ技術により、JavaScriptなしでもさまざまな機能を実装できる
- HTMLチェックボックスとCSSでトグル機能を実装できる
- HTMXを組み合わせれば、クリック時にデータを非同期ロードできる
最後の誤解: SPAなしではクライアント側コードがスパゲッティコード化する
- スパゲッティコードの時代にも、多くの生産的なソフトウェアが開発されていた
- 初期のMVP段階では、シンプルな構造のほうが有利な場合もある
結論
- 2024年現在、ブラウザはSPA革命から学んだことを取り込み、大きく進化している
- ブラウザ標準のツール（HTML、CSS、JavaScript）だけでも、インタラクティブでオフライン動作可能なアプリケーションを実装できる
- ブラウザの潜在力を信じて、もう一度活用してみることを勧める
8件のコメント
似たり寄ったりの開発者たちを集めて開発してみれば、これがどれほど夢物語じみた話かすぐ分かるはずです。これを書いた人は天才たちに囲まれているか、あるいは一人で仕事をしているようですね……（今さら古い
angularjsを持ち出しているのを見てもそうですし）。それに、開発は天才だけでするものでもありません。誰かは「似た者同士で固まっている」とけなすかもしれませんが、変化はいつだって平凡な人たちによって成し遂げられてきました。
こういうのを見ると、
htmxは絶対に受け入れられるべきではないのでは、という考えが先に浮かびます。最近また繰り返し出てくる話題ですが、
リッチ・ハリスが数年前にこのテーマについて自分の考えを話している動画があります。
https://www.youtube.com/watch?v=860d8usGC0o&t=635s
記憶している限りでは、partial HTML をベースに更新する方式は、画面とデータの不整合が生じる可能性がある、という要約になるでしょうね。
君はまだブラウザの仕様を信じているのか……?
強いて言えば、SPAはブラウザの挙動への依存が比較的少ないアプリ開発手法だと思います。
SPAの素晴らしい可能性にブラウザがかなり追いついてきていて、それがHTTPの本来設計された通信方式にもより合っているように見えるのは確かですが、それはChromeがブラウザの世界で事実上独占的な地位を持つことで余裕ができたからではないかと思います……。こういう状況が果たして長く続くのかは分かりませんね。余裕にせよ、シェアにせよ……
Phoenix LiveViewのように、WebSocketベースでサーバー側からDOMを操作する方式ならパラダイムが違いますが、
htmxを使ってみたときは、サーバーから断片的なHTMLを返さなければならないという点があまり気持ちよく感じられませんでした。
特にCSSの部分では、classを指定して返すとサーバー側は画面で使われているCSSを把握できないので、実質的に共通CSSを強制するような感覚です。
数年前に Phoenix LiveView でやや複雑な UI を作ってみたことがありますが、簡単なインタラクションを実装するのがあまりにも厄介で、1つの LiveView が 1 つの Elixir process として処理されるため、隣のコンポーネントとのインタラクションが非常に難しいです。結局あきらめて React に戻った記憶があります。
liveviewは未来みたいだと思います、私は…。
liveview はネットワークへの依存度もかなり高いので、サーバーが遠隔地にあって ping が高かったり、第三世界などインターネットインフラが良くない環境では弱点が大きいと感じました。
Hacker Newsの意見
ブラウザキャッシュを活用して静的なCSSやJSアセットを管理する方法が記事で触れられていない理由が気になるという声がある。過去にショッピングサイトをMPA方式で構築した際、ページ遷移はほとんど目立たなかった
PHPとjQuery時代のWeb開発が最も生産的だったと主張する人もいる。Reactなどの最新技術より、過去のパラダイムのほうが生産的なのではないかと疑問を呈する意見がある。AmazonやSteamのような大規模サイトも、依然としてサーバーでHTMLをレンダリングし、JSを追加する方式で作られている
サービスワーカー戦略が従来のHTTPキャッシュヘッダーと比べて何が優れているのか説明を求める意見がある。ネットワーク往復を減らせる一方で、小さな最適化のために全体を再発明しているようにも感じられる
"You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths" というタイトルは、省略された部分のせいでクリックを誘う印象を与える
プログラミングにおいて最も危険なのは、開発者の退屈さと過去に対する無知である
Node.jsのWebサーバー時代に、サーバー側とクライアント側（SPA）の二分法がなぜ存在するのか理解できないという意見がある。サーバーで大半の処理を初期化し、それをクライアントへシリアライズしてSPAとして動作させることはできないのか、という問いがある
SPAとMPAを互いに対立する陣営のように見る傾向があるが、Webスタックを自然に使う方法と「ハック」的な方法に分けて考えられる。SPAは現在のハック的手法だが、過去にはCGI、Javaアプレット、Flashなどがあった。こうしたハック的手法は、自然な方法の限界を拡張する役割を果たす
技術スタックの決定以前に、開発者が自分が何を書いているのかを誤解していることが多い。高いレベルの相互作用が必要でないなら、ほとんどの場合サーバーサイドのフレームワークで十分かもしれない
「シングルページアプリでなければインタラクティブなWebアプリは作れない」という神話への反論がある。SPAはより多くの制御を提供し、コードの一部を作り直す可能性を減らしてくれる
HNの見出しは実際の見出しよりも攻撃的である。これはTony AlaribeがBigSkyDevConで発表したエッセイであり、非SPAベースのWebアプリケーションを高速かつ滑らかにする技術を論じている。新しい技術も紹介されており、カンファレンスで最高の発表だったと考える人もいる