HTMX（やそれに似たもの）は、これをたくさん解決してくれるんだ。今のSPAを使うと、フロントエンドとバックエンドの2つのアプリを作ることになることが多いんだよね。俺はサーバーサイドでたくさん作りたいし、クライアント側にはちょっとしたインタラクティブな要素（表示/非表示、折りたたみ/展開、エフェクト）を追加したいんだ。でも、SPAの必要性はまだあると思うよ。

うーん、フルリロードしなきゃいけないのが一番痛いのは、サイトの効率性だと思う。実際のデータは数KBだけど、ページ自体は100MBダウンロードしなきゃいけなくて、ウェブブラウザは1GBのRAMを消費してる。Hacker Newsのナビゲーションがひどいとは思わないけど、ほとんどのナビはリロードだよ。2008年の4GB RAMのノートPCでも問題なく動くし。でも、同じデバイスでDoorDashに行くと、50アイテムのリストを読み込むのに30秒かかる。ダブルダッシュのカウントダウンをくれるけど、カレーを注文して6パックのソーダを手に入れるのに3分以内は無理だと思う。2.5分は、インターフェースが表示されるのを待ってる時間だし、ほとんどがフルリロードじゃないんだ。

スパのバックスワイプを使うと、ほとんどの場合ページのトップに戻っちゃうんだよね。アプリから出て戻っても効果ないし、マルチページのスパを作るのって本当に難しい。

チェックボックスセレクターを使えばできるよ。例えば、[0]を見てみて。俺はフロントエンドはあんまりやらないから、ChatGPTにコードを振ってもらったんだけど、これがベストな方法かは分からないよ。[0] https://html-preview.github.io/?url=https://gist.githubuserc...

一般的に言って、企業はカタログ全体をダウンロードさせたくないんだ。競合他社が簡単に分析できるようになっちゃうからね。もし本を売ってる店なら、何十万冊もあるかもしれない。そんなのをクライアントに転送するのは良い体験じゃないし、それに伴う帯域幅やメモリの使用も考えると、あまり良くないよ。

そうなんだよね、これって貴重な反例だと思うんだけど、リンクをシフトクリックして新しいタブで開く時（これってみんながよくやることだよね）、マルチページアプリケーションだと追加の手間はゼロなんだよね。でも、SPAだとそれを管理しなきゃいけない。もしリンクが存在しなくて、カテゴリにアクセスするのがセレクト入力だけだったら、UXはあまり良くないよね。

たくさんの雑なjQueryモジュールが本当にSPAの viable optionだったかは分からないな。人々はそれを試みたけど、SPAの時代はbackbone.jsから始まったと言えるよ。

低帯域幅や不安定な接続（攻撃的なキャッシングと組み合わせて）は、SPAを支持する最も強い理由の一つだよ（アプリケーションのAに重点を置いて、ウェブサイトではなくね）。良好な接続があるときにアプリのフロントエンド全体を訪れて（キャッシュして）、その後のアプリの使用は最小限の帯域幅で進められるんだ。

これって本当？古いSPAって言うと、ブラウザで動くJavaアプリを思い浮かべるんだよね。それは確実にjQueryよりも古いよ。（この質問をダウンボートするためにこのサイトを使うの、なんか面白い。）

でっかいjQueryスパゲッティを読み込むって言ってるけど、俺は早い段階からスコープを制限するためにIIFEみたいなJSデザインパターンを使って、コードを整理して構造化するのに時間をかけたんだ。モジュールの遅延読み込みやミニファイもね。とにかく、俺の経験では、AngularJSが構造化されたフロントエンドアプリケーションを作るための最大の試みだったと思うし、Java開発者にはすごく受けてた（Angularは今でも人気らしいし）。モジュール化や依存性注入、テストのしやすさが大きなポイントだった。Backboneでアプリを始めたとき（FlexアプリをiPadで動かせなかったから）、機能の大半はバックエンドにあると思ってテストなんていらないって主張してたんだけど、間違ってた。後にAngularJSでの再構築はフロントエンドのテストがかなり重要になったよ。今では、現代のAngularコードの冗長さや複雑さ、間接的な感じにはうんざりしてる。Javaコードも同様だけどね。

余談だけど、jQueryがいつもスパゲッティと結びつけられるのにはうんざりしてる。悪いプログラマーの手にかかれば、どんなTuring完全なシステムもスパゲッティになるんだよ。逆に、デザインを知ってる良いプログラマーの手にかかれば、シンプルでクリアになる。

SPAsが人気の本当の理由は、JavaScriptが新しいVisual Basicになって、何も知らない開発者が何百万もいるからだと思う。こういう市場の力は「帯域幅の最適化」よりもずっと大きな影響を与えるよ。俺の証拠はシンプルで、今まで見たSPAアプリは普通のHTMLよりも2桁遅いことが多かった。実際には帯域幅の利点なんてほとんどない。理論的にはあるけど、出会うアプリは半分のデータベースを流して、JSコードで数十バイトを選び出すだけ。ここでもこの議論の中にその意見があるよ！[1] 別の視点として、もしトップ100のサイトで莫大な帯域幅コストがかかっているなら、アプリをSPAに変えるのは経済的に意味があるかもしれない。でも実際には、小さなプロジェクトが初日からSPAで始まって、帯域幅のコストやパフォーマンスが影響することはほとんどないよ。ギガビットイーサネットでしかアクセスされない内部アプリも見たことがある。静的コンテンツがSPAとして表示されるのは、俺にはちょっと狂ってると思う。[1] 「ユーザーがカタログ全体をダウンロードする方が、はるかに良いUXだ」出典: https://news.ycombinator.com/item?id=44688834

もし現代的なCI/CDパイプラインがあるところで働いているなら、1日に何度もデプロイするたびに、その大きなJSバンドルを再構築してキャッシュを無効にしてる可能性が高いよ。HTTP/2はブラウザに採用されて10年くらい経つし、そのマルチプレクシングのおかげで大きな単一バンドルのパッケージングは関係なくなってる。大きなバンドルのパッケージングを使うSPAは、現代のブラウザやサーバーの機能を活かせてないね。

SPAは、アプリが複雑な状態を必要とする時にはいいよね。ネストされたタブが複数あったり、モーダルがあったり、動的にデータを読み込む複数の相互リンクされたセレクト入力があったり、ユーザーのアクションに応じてデータを遅延読み込みして更新するチャートやグラフがあったりする場合ね。ある程度の複雑さを超えると、データをその場で読み込む必要が出てきて（ページ読み込み時に全てを読み込むのではなく）、SPAを避けることはできなくなるんだ。SPAを作ることを選ぶのは、いつでも避けられるような気まぐれな決断じゃないこともある。時には、アプリの複雑さが分からないから、最初からSPAにする人もいるんだよね。そうすれば、後で出てくるかもしれない要件に対応できるかどうか心配しなくて済むから。一番最初の仕事の一つは、マルチページのEdTech「ウェブサイト」をSPAに作り直すことだったんだけど、マルチページサイトは非常に制限が多くて遅くて、複雑なユースケースには向いてなかったんだ。オーバーレイ機能がたくさんあって、それを別ページにするのは意味がなかったし。複雑な状態はURLに保持しなきゃいけなかったし、アクセス制御も微妙だった（HTMLを提供するよりも、リモートAPIコールでデータを混ぜ合わせる方が安全で、監視もしやすい）。SPAに対する批判の多くは、実はReactのような特定のフロントエンドフレームワークに関するものだと思う。多くの開発者は、スクロールバーをリセットするみたいな理由でReactが好きじゃないんだよね。Reactは、DOMを回避しようとするハックそのものだから。DOMは常に扱いにくくて拡張不可能だという前提で作られたけど、実際はそうじゃなかった。今では、カスタムウェブコンポーネントを使えば、DOMは直接扱うのがかなり簡単になったけど、この情報はReactの人気のせいで抑えられているみたい。Reactを含む多様なフロントエンドフレームワークで何年も働いてきたけど、Webコンポーネントの開発者体験は比べ物にならないほど優れているよ。期待通りに動くし、変なレンダリングのグリッチやタイミングの問題、掘り下げないといけない変な落とし穴もない。複雑なネストされたコンポーネントも作れるし、速いし、レンダリング順序も完全にコントロールできる。Webコンポーネントの中から属性を監視することで、自分の反応性を簡単に実装できる。得られる柔軟性と信頼性は、Reactのようなフレームワークとは比較にならないし、何もダウンロードする必要もないし、ライブラリをバンドルする必要もない（もしバンドルするなら、どのようにバンドルするか、どの程度までバンドルするかを選べるし、スクリプトやモジュールの事前読み込みを細かく制御できる）。コードもイディオマティックだよ。

読み込み後に本当に小さなネットワークリクエストを持つことと引き換えに。これが実際にどういうケースで、HTMLを送るのとは大きく違うのか、例を見てみたいな。私が関わったほとんどのSPAは、読み込み後に何十回も大きなリクエストをして、最初から同じ最終HTMLを送るよりもずっと遅くなっちゃう。JSONがHTMLよりも魔法のように圧縮されるって言えないし、HTMLはすごく圧縮がうまくいくからね。ネットワークの懸念がSPAをより良い選択にするという議論の多くは、実際にはプロパガンダか、実践ではうまくいかない迷信だと思う。

これはちょっと unfair だと思う。LinearはSPAの中でも特別だし、普通じゃないよ。「SPAを禁止して、ブラウザからJavaScriptを取り除け」なんて誰も言ってないし。Linearの速さは「オフラインファースト」から来てるけど、同じようにやってる一般的な製品を挙げてみてほしい。そんなの普通じゃないから。チケットを買いたいときは、ほとんどのウェブサイトがSSRで、必要なところだけSPAにしてほしいな。フォーラムやニュースサイト、ブログ、情報サイトなんかもそう。SSRで開発した方がいいものがたくさんあって、CSSでSPAっぽくする方が、実際にSPAにするよりも良いと思う。

誰もSPAに場所がないとは言ってないけど、99%のウェブサイトはSPAである必要がないよ。

戦争があったの？初耳だわ。「Nextが勝った」と言うのは「Reactが勝った」と言うのと同じ。何も勝ってないし、みんなが群衆が支持したと思ったものに飛びついただけ。盲目の者同士はお互いを導けないよ。Angularやミニマル、フレームワークなしにこだわってる人たちは、みんな何を話してるのか本当に不思議がってる。FacebookのドキュメントもNextに直結してるし、スタートアップやSVはお互いを持ち上げ合ってる（アフィリエイトみたいなもん）。でも、それには何の意味もない。Nextは多分ゴミフレームワークだけど、それが人々の生計に関わってる。人を定義するものを消すのは本当に難しいよ（そう、あなたの履歴書はあなたそのもの）。

それがキャッチーで繰り返しやすいから、彼の広い主張（SEO）にぴったりなんだよね。皮肉なのは、私はページ遷移なしでたくさんのSPAを作ってきたから（それが必要な要件じゃなかったから）、ページ遷移が簡単だから追加し始めたってこと。