2025年のReactとBackboneの比較

元記事: 2025年10月25日原文(backbonenotbad.hyperclay.com)

概要

2010年のBackbone と 最新のReact の比較
コード量や目的はほぼ同じ
Reactの抽象化 による複雑性の増加
実装の分かりやすさ と デバッグの難しさ
今後求められる 新しいモデル への期待

15年の進歩

Backbone（2010年） と React（最新） の実装比較
コードの長さや機能はほぼ同等
Reactは巨大なエコシステム と 多大な開発工数 を背景
進歩の本質は「どれだけ良くなったか」ではなく「どれだけ変わっていないか」
進化の実感の薄さ が浮き彫り

シンプルさの錯覚

Reactは見た目がクリーン で読みやすい印象
その可読性は 抽象化による複雑性 の代償
Backboneは処理の流れが明確 で、初学者でも追いやすい
「このイベントが起きたら、この処理をする」という 直感的なモデル
Reactは多くを隠蔽 し、内部の理解がなければ問題解決が困難

React特有の落とし穴

リストアイテムのkey をindexにしたことで stateが消える 現象
inputのvalueがundefined になり、制御不能・制御済みの切り替えでリセット
useEffectで無限ループ ：依存配列に毎回新しいオブジェクトが入る
useMemoやuseCallback で「識別子の安定化」が必要
クリックハンドラが古いstateを見る ：クロージャの罠
setStateの関数型更新 や依存配列の調整が必要
どれも 本質的な課題 ではなく、 React固有の対処法 を強いられる

魔法の代償

これらの問題は 珍しいものではなく日常的
デバッグにはReact内部の深い理解 が必要
「なぜ動くのか分からないまま動く」ことの危うさ
仮想DOMのdiffやスケジューリング の知識が求められる
BackboneやjQueryはハックしやすく、透明性が高い

次に求められるもの

本質は「 イベント＋状態＝UI」のシンプルな方程式
大規模アプリ にはReactの複雑さも意義あり
しかし 大多数の小規模アプリ には過剰な魔法
直感的かつ堅牢、ハック可能な新しいモデル への期待
BackboneやjQueryのように中身が見える開発体験 の復権

出典: panphora

提供: ハクソク · 要約更新: 2025年10月26日

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

ReactとBackboneについて、時々考えることがあるけど、結論はちょっと違うんだよね。Backboneは僕の最初の「JSフレームワーク」の一つだった。面白いと思ったけど、Reactが出た時に「お、実際に役立つものだな。Backboneは主にアプリケーションフレームワークの接着剤みたいなもので、あんまり自分には役立たないな」と思った。Reactから得た具体的な大きなメリットは、 - DOMに定期的に触れなくていいこと - リアクティブな状態管理これらの二つは、プログラマーとしての僕の生活をかなり楽にしてくれたし、スパゲッティみたいなソフトウェアを作らない能力も育ててくれた。

└

Reactには組み込みの状態管理機能があるの？

└

ちょっと懐かしいな、昔Backboneのチュートリアルをたくさん書いてたんだ。 https://news.ycombinator.com/item?id=3110025 https://web.archive.org/web/20111015073638/https://backbonet... インポートがない以外は、15年後でも嫌いじゃないよ。LLMのおかげで、コーディングについての考え方がかなり変わった。どのように言語を書けばLLMが最も効果的に書けるかに興味がある。JSX/宣言的なものは結構しっかりしてると思う。useEffect以降のReactコミュニティはちょっとふわふわしてきてる気がする。多分、LLMが「考える」にはあまり良い方法じゃないんじゃないかな。（表現力、明示性、解析可能性について何かある）

└

MarionetteはBackboneのボイラープレートをかなり減らしてくれたけどね。

1,000コンポーネントが同じページにあるような大規模アプリでは、Reactの複雑さは正当化されるかもしれない。でも、他の99%のアプリはどうなの？コンポーネントの数だけが複雑さの指標じゃないよ。UIを構築する際の複雑さの大部分は、状態管理や状態変更がストアとUIにどう伝播するかから来る。僕はBackboneを何年も使ってきたけど、UIが状態変更のカスケードでフリーズしてデバッグに何時間もかかったことをはっきり覚えてる。それはBackbone Storeを使っていたからで、双方向のデータフローがあって、ストアを更新するとUIが変わり、それがまた状態ストアを変えて、UIが変わる、みたいな感じだった。Reactの本当の革新は「単方向データフロー」だと言えるかもしれないけど、ReactチームはFluxアーキテクチャをフレームワークの中心に据えて、良いプラクティスを採用しやすくした。一方でBackboneはストアに依存せず、長年オブザーバーパターンを使ったBackbone Storeを推奨してた。成功の落とし穴にハマれるフレームワークを選ぶべきだと思うし、Reactはそのフレームワークだったし、今でもそうだと思う。

└

1,000コンポーネントが同じページにあるような大規模アプリもしページに40X25の編集可能なテーブルがあったら、それが1,000コンポーネントになるね。でも、テーブル以外では、1,000以上のコンポーネントを一つのページに持つのはやりすぎに思える。

└

Reactの本当の革新は「単方向データフロー」だと言えるかもしれないこれはDOMの動き方そのものじゃない？データは属性やプロパティを通じて下に流れ、イベントは上にバブルする？ > でもReactチームはFlowアーキテクチャをフレームワークの中心に据えたんじゃない？彼らはFlowではなくFluxと呼んでたよね？

└

コンポーネント自体が追加の複雑さの一形態なんだ。アイデアは、構成され自己完結したコードの島を提供すること。これを達成するためには、大量のマークアップ、プレゼンテーション、イベント処理、ビジネスロジックの記述、そして前述の抽象化を補うためのセキュリティやアクセシビリティのロジックが必要になる。エディタで見るものはあまり見栄えがしないかもしれないけど、その裏には膨大な無駄が隠れている。なんで人々はこれを好むの？メンテナンスの速度は上がらないのに。開発者が快適に感じる事前定義されたアーキテクチャスキームに組み込めるから好まれるだけなんだ。それだけ。結局は快適さの問題だけど、複雑さはとんでもないことになってる。シンプルなものはタダじゃない。

└

双方向データフローがあり、ストアを更新するとUIが変わり、それが状態ストアを変えて、またUIが変わる、という問題がある。Reactでも同じ問題が起こるよ。循環する状態更新。状態変更→useEffectをトリガー→状態を変更。これ、Reactを始めたばかりの頃にぶつかったことがある。

└

人々は、React/Flux/Reduxの前のフロントエンド開発がどうだったかを思い出さないし、思い出せないこともある。1000行未満のシンプルなページでも、状態管理で問題が起こることが簡単にあったよね。もちろん、対策はできたけど、全然簡単じゃなかった。

└

私は何年もAngularを使っていて、最近新しいプロジェクトのためにフロントエンドの仕事に戻ってきた。これが私のReactの経験で、完璧ではないし、いくつかのReact特有のことを学ぶ必要があるけど、正しいことをする傾向があるよ。

└

ここでの著者です。単方向データフローが実際の問題を解決するという点には感謝していますが、実際には一つの複雑さを別の複雑さに置き換えているだけだと思います。確かに、Backbone Storeの状態変更のカスケードはデバッグがフラストレーションでした。でも、Reactの抽象化は同じくらいフラストレーションを引き起こす問題を引き起こします。古い状態を参照するクリックハンドラーの古いクロージャー、依存配列のオブジェクトが毎回再生成されるための無限のuseEffectループ、安定からインデックスベースに変わったために起こる神秘的な入力クリアリング。違いは、Backboneの問題は明示的で可視化されていたことです。何かが壊れたとき、イベントハンドラーを追跡して、何がいつ発火したのかを理解できた。複雑さは目の前にあったから、デバッグ可能だった。Reactの問題は抽象化の背後に隠れている。Reactが問題を解決しないとは言っていませんが、それらの解決策がFacebook規模ではない99%のアプリに適切かどうかを疑問視しています。時には、明示的で冗長なアプローチの方が、長期的には考えやすいこともあるんです。

Hacker Newsで議論の続きを見る