モダンCSSがSPAに取って代わる時代です

 (jonoalderson.com)
17 ポイント 投稿者 GN⁺ 2025-07-26 | 10件のコメント | WhatsAppで共有
  • View Transitions API のような モダンCSS機能 の登場により、滑らかなページ遷移のためにSPA構造が必要ない状況になった
  • ほとんどの SPAサイト は実際には期待されたほどの 性能や滑らかな体験 を提供できず、むしろ重いJavaScriptコードがユーザー体験を損なう傾向がある
  • Chromiumベースのブラウザで ネイティブなページ遷移 と Speculation Rules を活用すれば、JavaScriptなしでも高速で自然なナビゲーションを実現できる
  • SPAの複雑な構造は ブラウザ最適化 を妨げるため、実際のWebサイトではHTMLとCSS中心の MPA構造 の方が速く、管理もしやすい
  • 今後は 不要なSPA導入を避け、モダンCSSとネイティブ機能を活用して 効率的で保守しやすいWebサイト開発 が必要になる

序論: SPAの終焉とモダンCSSの登場

  • 最近 View Transitions API のような最新CSS機能が導入されたことで、従来SPA（シングルページアプリケーション）が提供していた主な利点は もはや不要になりつつある
  • いまなお多くの開発チームがReactやVueのようなSPAフレームワークを選んでいるが、その判断の核心は性能ではなく、インタラクションと滑らかなナビゲーション体験に対する誤解 にある
  • 滑らかなナビゲーションのためにSPAが必須だと信じる慣行は、すでに時代遅れの発想である

SPAの幻想と現実

  • SPAはかつて最も 自然なページ遷移 を実現する唯一の方法だったが、いまはもはやそうではない
  • 多くのSPAでは次のような問題が発生する:
    • ローディング状態のフェード効果 があるだけで、真のコンテンツ遷移の滑らかさに欠ける
    • スクロール復元の問題 と 一貫しないフォーカス処理
    • レンダリング/ハイドレーション遅延によるナビゲーションの遅れ
    • レイアウトシフトやコンテンツのポップアップ、スケルトンローディングなど
    • 性能に対する効果が乏しい不要な複雑性とJavaScriptの過剰使用
  • 代表的なSPAフレームワーク（Next.js、Gatsby、Nuxtなど）は、基本的なネイティブブラウザ動作を模倣 するために大量のJSコードを追加している
  • その結果、ネイティブな自然さを犠牲にし、速度が遅くなりSEOも低下する問題を招いている

Webプラットフォームの進化とCSSの役割の変化

  • 最新の Chromiumベースのブラウザ（Chrome、Edgeなど）では、ネイティブで宣言的なページ遷移をサポートしている
  • View Transitions API によって、JavaScriptなしでもドキュメント間あるいはページ全体にまたがる滑らかなアニメーションを実現できる
  • 主な能力は次のとおり:
    • ページ間の フェード効果（わずか3〜4行のCSSで実装可能）
    • サムネイルから詳細画像への自然な遷移などの 共有要素アニメーション
    • ヘッダー、ナビバーなどの 永続要素の維持
    • 実際のURLと実ページ遷移であるため、SEO、リンク共有、戻る/進むキャッシュなどとの互換性を最大化

CSSとJSのシナジーを十分に活かす方法

  • 必要であれば、JSによって ページ内部の遷移にもView Transition を手動で呼び出せる
  • 例: テーマ切り替え、タブ切り替え、ダークモード切り替えなどに最小限のJavaScriptだけを使う

Speculation Rulesと即時ナビゲーション

  • Speculation Rules は、ブラウザがページをあらかじめ プリロード/プリレンダリング しながら、ユーザー行動（例: マウスオーバー）を予測して即時ナビゲーションを提供する
  • 宣言的に <script type="speculationrules"> を通じて設定できる
  • 前提: ページが軽量で最適化されているときに パフォーマンスを最大化 する効果があり、重いページでは逆にリソース浪費の危険がある

ブラウザ固有機能の尊重とbfcache

  • bfcache（Back/Forward Cache） は、ユーザーが戻る/進む操作をした際にページ全体をスナップショットの形で即座に復元する
  • 前提条件: 純粋なHTMLとCSSベースのクリーンなアーキテクチャ である必要があり、SPAのようにルーティングを横取りする構造では適用できない
  • 結論として、モダンブラウザは単純で堅牢なWebサイトに報いる 方向へ進化している

SPAとMPAのパフォーマンス比較

  • 平均的なSPA（Next.js基準）:
    • JSバンドルサイズ: 1〜3MB
    • TTI（操作可能になる時点）: 3.5〜5秒
    • ルート遷移: 偽の/シミュレーションされたもの
    • SEO: 複雑で維持が難しい
    • スクロール/アンカー動作: 不安定
  • モダンMPA（CSS遷移およびSpeculation Rules適用）:
    • JSバンドル: 0KB（任意の補強のみ）
    • TTI: 約1秒
    • ルート遷移: 本物のネイティブ動作
    • SEO: 非常に容易
    • スマートスクロール、フォーカス、履歴: ブラウザの標準動作として完全対応

Webサイトとアプリの区別、適合性の再考が必要

  • 大半のWebサイトは実際には「アプリ」ではなく、共有状態、クライアントルーティング、複雑なインタラクション を必要としない
  • マーケティングページ、ドキュメントポータル、EC、ブログなどには、HTML中心、高速ロード、シンプルな構造 の方が適している
  • あらゆるプロジェクトでSPAスタックを導入すると、過度な複雑性 と性能低下を招く可能性がある
    1. 「アプリのように見せたい」という要求
    2. フレームワークの導入
    3. クライアントルーティングと複雑性の増加
    4. 性能低下と追加最適化の必要
    5. それでもネイティブリンク遷移 + CSSアニメーション構造より遅い現実

結論と提言

  • SPAは過去の プラットフォームの限界 に対する暫定策に近かったが、現在ではその制約はもはや存在しない
  • いまは次のような ネイティブ機能 を積極的に活用できる:
    • 本物のページ間遷移
    • Speculation Rulesによる即時の事前レンダリング
    • 段階的機能低下に強い構造
    • すっきりしたマークアップ、高速ロード、実URLの活用
    • プラットフォームの恩恵を最大限に受けられる構造
  • 「滑らかさ」だけを理由にSPAに固執すると、複雑性、性能、保守性 のすべてで代償を払うことになる
  • サーバーレンダリング、実ページ、CSSベースのアニメーション、意図的な事前ロード、最小限のJS を導入することで、現代に合った高速で快適なWebサイトを作れる
  • 2025年現在の技術を活用し、より速く、より簡単で、誰にとっても歓迎されるWeb体験を目指すべきである

関連記事

10件のコメント

 
nemorize 2025-07-29

そもそも「滑らかさ」だけを理由にSPAを検討するような場面なら、ただその滑らかさを諦めてMPAで作ればよかっただけなので、あまり共感できませんね……
 
longface0908 2025-07-29

この記事の惜しい点

  1. SPA の本来の目的を矮小化して解釈している
    View Transitions API は本当に素晴らしいが、それだけで SPA が不要になるわけではない。

  2. すべての Web サイトを同じ基準で見ている
    マーケティングサイト ≠ ダッシュボード ≠ コマースアプリ ≠ リアルタイム共同作業ツール
    それぞれ異なる構造的要件を持っている。

  3. 実運用では SPA + SSR + MPA が共存している
    Next.js のようなハイブリッドフレームワークがそれをよく示している。
    静的アセットは SSG、ログイン後のダッシュボードは CSR/SPA、検索エンジン対応は SSR など、柔軟な組み合わせが必要だ。

SPA はユーザー体験だけでなく、構造改善の産物に近いと思います。
SPA が不要なページには MPA + モダン CSS が良い選択肢になり得ますが、SPA は構造、状態、拡張性、保守性の面で依然として必須です。モダン CSS は SPA を「補完」することはできても、「代替」することはできないと思います。
 
spp00 2025-07-29

SPAを、ビュー・トランジションなどで置き換えられないものは、あなたが提示した事例の中ではリアルタイム協業ツールしかありませんし、大多数のWebサイトはリアルタイム協業ツールではありません。マーケティングサイト、ダッシュボード、コマースアプリはいずれも、SPAフレームワークを排し、サーバーレンダリング、実ページ、CSSベースのアニメーション、意図的なプリロード、最小限のJS導入という条件を守りながら構築することが可能です。これを志向するRails陣営のHotwireもあり、これにはBasecampとHEYという本番運用の事例もあります。状態管理？ リアルタイム協業ツールのようなものでない限り、URLパラメータ、サーバーセッションのようなサーバー側の方法や、ローカルストレージで十分可能です。ページ遷移を見てSPAを導入する事例も確かにありますし（AGF公式サイトのようにAstroでも十分なのにReactを導入した事例は確実にあります）、SPAの代表的な利点としてよく挙げられるのがページ遷移であることは否定できません。
 
sonnet 2025-07-29

現在のSPAフレームワークと、それに基づくフロントエンドのトレンドについては、非標準化に対して引き続き警戒する必要があることも、オーバーエンジニアリングや不要なリソース消費を招きやすいことも事実ですが……

SPAという概念自体についてもあまりに狭く見ていますが、それ以上に、SPAフレームワークが開発全般にどのような影響を及ぼすのかを理解しているのか疑問に感じます。

View Transitions APIひとつで、CSSさえあれば全部できるという話は、言い換えれば、それと関係のないあらゆる機能、そしてそれを実現するためのパラダイムがすべて無意味だということになりますが、あまりにも傲慢な見方ではないかと思います。

パンフレット代わりになる程度のサイトをReactで作ったときのオーバーエンジニアリングとは、また別の問題でしょう。

大半の小規模プロジェクトで、あえてSPAフレームワークが必要ないという点には同意しますが、複雑なインタラクションと継続的なユーザー体験、そしてそれに伴う保守や継続的改善を要件とするサービスでは、CSSが進化した今でも、そうではないと考えます.
 
sonnet 2025-07-29

正直、触ってもいないRustやHaskellについて『そんなものがなくても、今どきはC++で全部できる』と言っているように見えます。
 
ahwjdekf 2025-07-28

うーん、どうでしょう。SPAフレームワークを使う目的は、滑らかな画面遷移というより、ユーザーとの複雑な相互作用のためではないでしょうか？
 
spp00 2025-07-29

滑らかなインタラクションのためだけにSPAフレームワークを導入するケースも確かにあります。SPAが適用されたサイトのかなりの部分は、複雑なインタラクションを必要としていません。
 
howudoin 2025-07-27

強く同意します
端的な例として、React自体もフロントエンド版のSpringです
重くて複雑で、業務は便利になったように見えますが、実際には軽い仕事をするためにより複雑な手順を設定し、そのうえでわざわざ複雑になった手順を便利にしているという、妙な便利さです
 
spp00 2025-07-27

同意します。Google Docsのような複雑なWebアプリでなければ、Rails陣営が作ったHowiredでも十分ですし、静的ページならAstroでも十分だと思います。
 
GN⁺ 2025-07-26
Hacker Newsの意見

  • SPAは、ユーザーが1つのアプリで長時間のセッションを過ごす場合に意味がある。つまり、一度大きなバンドルを読み込めば、その後は小さなネットワークリクエストだけでアプリを使えるようになる構造だ。滑らかな画面遷移はおまけにすぎず、SPAが解決する本質的な問題ではないと思う。クライアントサイドルーティングがページ遷移のためのものだという主張は、SPAの目的を誤解している。もしそうした誤った前提でSPAを使っていたのなら、この記事は正しいが、SPAはjQuery時代の複雑なアプリのために登場した。巨大なjQueryコードの塊で、各divがミニアプリのように動き、多数の小さなネットワークリクエストで同期していた。古いブラウザと遅いインターネット環境で、毎回コード全体を再読み込みせずに効率よく使えた。その後、Reactなどのフレームワークが構造的なアプリ開発をしやすくしながら発展し、SPAの核心的な利点は、長時間利用するユーザー向けに一度大きなバンドルをキャッシュし、その後のネットワークトラフィックを最小化することだ。

    • （上の意見の引用: "...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.") まったく同感だ。筆者はSEOコンサルタントで、マーケティングサイトのことしか見ていないように思える。実際のアプリ（マーケティングサイトではない）はSPAで大きな恩恵を受けられる。たとえばGoogle MapsをSPAなしで作るところを想像してみれば、ページ遷移アニメーションを加えただけでもUXは深刻に悪化するだろう。

    • 「jQueryスパゲッティを積み上げただけ」という表現があるが、実際には私はIIFEのような初期のJSデザインパターンを適用して、コードの構造化やモジュールの遅延ロード、コード難読化などをやっていた。そして私の経験では、AngularJSはフロントエンドの構造化の試みの中で最も大きく、Java開発者に魅力的だった理由も、モジュール化、DI、テストのしやすさにあった。最初にBackboneでアプリを作っていたときは、機能の大半がバックエンド側にあるだろうと思っていたので、テストはあまり気にしていなかったが、後にAngularJSで作り直した際には、フロントエンドのテストがずっと増えた。もちろん今どきのAngularコードやJavaコードの冗長さ、複雑さ、間接性には抵抗を感じる。

    • 遅いネットワーク接続と積極的なキャッシュ環境は、SPAが必要になる強い理由の1つだと思う（Webサイトではなくアプリケーションでより当てはまる）。まともな接続があるときにフロントエンド全体を一度受け取ってキャッシュしておけば、その後の利用は最小限の帯域で済む。

    • 現代的なCI/CDパイプラインを使う環境で働いているなら、1日に何度もデプロイするたびに、その大きなJSバンドルが再ビルドされ、キャッシュが無効化される可能性が高い。HTTP2はすでにブラウザで10年間デフォルトになっており、マルチプレクシングのおかげでJSバンドルを大きくまとめる理由はなくなっている。大きなバンドルを作るSPA方式は、ブラウザとサーバーの現代的な機能を活かせていない。

    • 読み込み後のネットワークリクエストが本当に小さくなった事例が、実際にどれほどあるのか気になる。私が経験した大半のSPAは、読み込み後も大きな呼び出しが多く、単にHTMLをそのまま送るよりずっと遅かった。JSONがmagicallyにHTMLより圧縮しやすいという主張も成り立たない。HTMLも十分よく圧縮される。実際には、ネットワークの問題でSPAの方が優れているという議論は、ほとんど宣伝か迷信に近い。

  • SPAの価値は滑らかな遷移だけではなく、ユーザーの行動の大部分をクライアント側で処理し、サーバーをほとんど意識しなくて済む点にあると思う。例として、2025年になっても大半のオンラインショップが、フィルター変更やカテゴリ移動のたびにページ全体を再読み込みし、再びデータを取りに行かなければならないのが不満だ。ユーザーがカテゴリを行き来して何度もリクエストする状況では、カタログ全体を一度クライアントに落としておき、その後はサーバーとの通信なしでフィルタリングできれば、UXはずっと良くなる。もちろんデータ量が多いという反論はあるだろうが、大半のショップのカテゴリは数KBで十分で、商品画像1枚よりも小さい。2005年からこういうアプリを作ってきたが、なぜこうしたUXがもっと広く使われないのか、いまだに理解できない。

    • 私の考えでは、ページをフルリロードしなければならない一番不便な点は、データサイズではなくサイトの効率性だ。実際のデータは数KBなのに、ページ自体が100MBをダウンロードし、ブラウザが1GBのRAMを消費する。たとえばHacker Newsはほとんどのナビゲーションが再読み込みだが、古いノートPCでも問題なく動く。一方でDoorDashのようなSPAは、同じ端末で30秒もかかり、実際に料理を注文するまで3分以上かかった。インターフェースが表示されるまで2.5分待たされ、その時点でもほぼすべてがフルリロードではなかった。

    • HTMXのようなツールが、こうした問題をかなり解決してくれる。SPA方式は結局、フロントエンドとバックエンドという2つのアプリを別々に作る結果になると思う。私はサーバーサイドで大半を処理し、クライアント側では単純なインタラクティブ効果（表示/非表示、展開/折りたたみ、エフェクトなど）だけを追加する方がよいと感じる。もちろんSPAが有用な場面もある。

    • 似たような経験として、いくつかの個人プロジェクトは静的Webサーバーにホスティングしている。何万もの個別ページをレンダリングする代わりに、1つのJSONファイルをSPAでクライアントレンダリングしている。Github Pagesも使った。最近ではsqliteデータベースのwasmビルドを使い、HTTP Range Requestsで必要なページだけを受け取る構造も試している。sqliteのFull Text Searchも動くことは動くが、短い検索ではテーブル全体を受け取らなければならないのが惜しい。DB全体を受け取ってローカルでFTSテーブルを作る方がよいかもしれない。

    • 反論の例もある。たとえば「sci-fi」カテゴリをShiftクリックして新しいタブで開くとき、MPAなら特に努力せずできるが、SPAではこれを別途管理しなければならず面倒だ。もしカテゴリリンクがなく、Select BoxからしかアクセスできないならUXはいまひとつだ。

    • 一般に企業は、カタログ全体をユーザーにダウンロードしてほしくない。競合が簡単に分析できてしまうからだ。また書籍販売のようなケースでは数十万冊に及ぶため、それをすべて一度に移すのは、ユーザー体験の面でも帯域やメモリの面でも非効率だ。

  • SPAの目的は決してページ遷移ではない。優れたページ遷移をきちんと実装したSPAはほとんどない。たとえばNext.jsではルートの読み込み方式のせいで、ページトランジションの実装はほぼ不可能に近い。実際に私はNext.jsに適切なページ遷移機能を追加してみたが、完全に悪夢だった。SPAの明確な利点は次の2つに見える。第一に、大半のアプリはある程度のインタラクティブ性を必要とするので（HTML/CSSだけでは不十分）、Reactと生のHTMLを混在させるのは非常につらい（特にグローバル状態管理が必要なとき）。第二に、ページ構造全体を先に読み込んでおけば、その後のデータ読み込みが速くなり、クリック後に即座に反応してローディング画面を出せる方が、500ms後にやっと反応するよりUXが良い（100ms未満なら話は別だが）。ページ全体を再描画する必要がないため、フロントエンド性能はHTMLだけでは太刀打ちできない。Basecampのように複雑なWebアプリをSPAなしでうまく作った例もあるが、30秒ほど触ってみるだけでもSPAの性能には及ばない。Web本来のあり方で動いてほしいとは思うが、Next.jsやSPAが追加する複雑さは、アプリをより速く反応的にした一方で、開発を面倒にし、大きなバンドルを生む弊害もある。それでもHTMLだけでは、まだSPAの性能には追いつけないと思う。

      1. APIの観点もある。すでにiOS/Androidアプリや開発者向けAPIがあるなら、SPAはそのバックエンドにもう1つのアプリを追加する形になるので、連携しやすい。

  • この記事を書いたSEOコンサルタントがどこの宇宙に住んでいるのか分からない。NextやNuxtをSPAに対立する代表的フレームワークのように例示するのは完全に間違っている。1. Nextは米国/西側圏でほぼ完全に覇権を握っており、新しいReactアプリの話をするとき、大抵はNextを指している。Vue陣営ではNuxtがほぼ標準で、Nuxt = Vue界のNextだ。つまり人々は無意識にNextとMPA戦略を選んでいる。振り子はMPAに振れすぎたので、むしろSPAを試してみるよう勧めるべきだと思う。ここ8年はMPAへの回帰ブームであり、今やFacebookも公式にCreate React AppではなくNextをドキュメントで勧めている。2. Nextの複雑さへの不満は、最新のMPA戦略の難しさに関するもので、SPA陣営ではほぼ10年前から止まった話だ。3. MPA開発はSPAよりずっと難しい。サーバーとクライアントの境界をより厳密に守らなければならないからだ。4. SPAでMPA方式のデータ取得をしたいなら、それは開発者の選択であり、長所短所は自分で引き受けるべきだ。先にデータを読み込んでSPAナビゲーションを即時化することもできる。5. 本当にSEOが重要なメインのフロント以外にも、内部ダッシュボードやアプリはもっと多く存在する。React開発者はたいていそういう場所に多いので、初回フレームを完璧に出そうとする負担から生まれる不要な重荷を持たないことが重要だ。

    • 「本当にそんな戦争があったのか？」という疑問が湧く。Nextが勝ったというのはReactが勝ったと言うのと似ている。誰も勝ったわけではなく、ただ時流に乗っているだけだ。Angularやミニマル、あるいはフレームワークなしの開発スタイルを貫いてきた人は、本気で「みんないったい何の話をしてるんだ」と思っているだろう。そしてスタートアップ界隈とシリコンバレーは、互いに宣伝し合いながら離合集散するようなものなので、実際にはそれほど大したことではない。Nextはいまひとつかもしれないが、すでに多くの人のキャリアやアイデンティティがそれに絡んでいるので、簡単には消えないだけだ。

  • SPAを貶す論調は不公平だと思う。SPAは確かにより多くの労力を要するが、利点も明らかに多い。アプリのように感じられるUXを作る唯一の方法が、長い間SPAだった。筆者はアプリ疲れに言及しているが、本当に「アプリケーション」らしい体験を提供するには、SPAがほぼ唯一の手段だ。重いSPAと軽いWebサイト（静的サイト）を比較するのは不適切だ。軽いWebサイトを作れる人なら、同じように軽いSPAも作れる。SPAであれWebサイトであれ、非効率に作れば遅くて重いのは同じだ。SPAに多く投資してきた立場として、より少ない労力で同じ体験を出せる方法には強い関心があったが、この記事は多少の視覚的な装飾に近い。ポリシーは価値があるが、SPAかどうかを決めるほどの影響力はないと思う。

    • 「でも、より良い」というその主張の根拠が知りたい。

  • 「SPAフレームワークなしでlinear.appを作ってみろ」というのは無理があると思うし、「Native CSS transitionsでSPA最大の利点（クライアントルーティング）が死んだ」という命題は意味をなしていない。

    • LinearはSPAの中でもかなり特殊なケースだと思う。SPAを禁止しようとか、ブラウザからJSを完全に取り除こうという話ではない。Linearが速いのは「オフラインファースト」設計だからだが、そうしているサービスはほとんどない。チケット予約やフォーラム、ニュース、ブログ、情報系サイトはSSRベースの開発の方がずっと向いていると思う。SPAが本当に必要なところにだけSPAを使い、それ以外はSSRで素早く開発し、CSSでSPAっぽく見せる方がはるかに効率的だ。

    • SPAの居場所がないわけではないが、残りの99%のサイトはSPAである必要がない。

  • SPAはビュー遷移（ページ遷移）のためのものではない。原文（TFA）はページ間の派手な遷移が重要だと示唆しているが（これは誤りだ）、「CMO」や「ブランドマネージャー」のせいにするのではなく、SPAの本質的な価値に光を当てるべきだ。SPAはクライアントロジックのための優れたフレームワークであり、関心の分離（フロントロジックとバックエンドの分離）、開発体験の改善→開発速度の向上など、さまざまな利点がある。こういう記事がよく見られるのは、私のコメントのように議論を呼ぶ構造になっているからだが、実際にはそこまで注目されるべき記事ではないと思う。

    • こうした話題は流行性と反復性があるから広がるのだろう。原文の著者がSEOに注力していることともぴったり一致する。実際、ページ遷移がまったくないSPAも数多く作ってきたし、最近はビュー遷移のおかげで遷移効果を入れることもあるが、必須ではなかった。

  • 私の立場では、SPAの主な約束は滑らかな遷移ではなく、バックエンドと完全に分離されたデータAPIとフロントエンドを作れることにある。だからSSRとクライアントレンダリングを混ぜるのは好きではない。いっそWebサイトかアプリか、どちらかであるべきだと思う。

  • 「SPAとMPAの基準は何か？」という疑問がある。私のNext.jsベースの個人サイトは、実際にはほぼすべてをサーバーサイドレンダリングしている。technicallyにはSPAだが、JSを有効にするとRSCとクライアントサイドナビゲーションが動き、JSを無効にしてもクライアント専用コンポーネント（例: QRコード生成器）は代替コンテンツとして表示され、残りは完全にSSRでレンダリングされるので、多少遅く感じるものの問題なく動く。コンポーネントをサーバーでレンダリングしない方が、むしろ手間がかかる。Progressive enhancementが最高だ。

    • 「SPAとMPAの基準」は、appのWindow loadイベントが何回発生するかで判断できる。

  • それに、SEO業界やコロナ後に入社した新人Web開発者たちが、SPAをしきりに誤解して貶しているのが本当にもどかしい。2000年代から開発してきた立場からすると、SPAの本当の起源は、原文にあるような「偽りの約束」のためではなく、2000年代後半から2010年代前半にかけてモバイルファースト戦略が広まり、frontendとbackendを完全に分離しなければならなくなったことにある。それ以前はフロントエンドといえば、サーバーでテンプレートからHTMLを描画して、そこにjQueryを少し載せる程度が一般的だった。しかし今では、モバイルとデスクトップアプリの両方が同じビジネスロジック/DBを使う必要があるため、REST構造やRoy Fieldingの論文を読み直し、サービス指向アーキテクチャとAPIの外部公開が主流になった。コスト最適化の側面もあった。この時期、Ruby on RailsやDjangoのようなフルスタックWebフレームワークは一時的に停滞期を迎えた。Node.jsが台頭し、ブラウザとモバイルもますます高性能になったことで、多くのビジネスロジックを「エッジデバイス」側、つまりクライアントに載せられるようになった。SPAの核心はまさにここにあり、CSSがその必要性を代替することはできない。