Reactでなければ、何を使うべきか？
(infrequently.org)> 「Frameworkism（フレームワーク主義）はもはや通用しない。答えは別のツールではなく、エンジニアリングする勇気だ」
- この10年間で、デスクトップおよびモバイルWeb向けのさまざまな製品と技術スタックを通じて、100件を超えるプロジェクトを経験
- 多くの時間は、Web API の改善よりも、React のようなフロントエンドフレームワークが引き起こしたパフォーマンスとアクセシビリティの問題を解決することに費やされた
- React はすでにレガシー技術であるにもかかわらず、依然として新規プロジェクトで採用されている
- React を「モダン」だと主張する人もいるが、それは過去のやり方を繰り返しているにすぎない
最小限のクライアントサイド複雑性の原則
- サーバーサイドコードは開発者が制御可能であり、性能と可用性を効果的に管理できる
- クライアントサイドコードは開発者が制御できない多様な環境で実行されるため、安定性と性能を保証しにくい
- 最善の戦略は、クライアントに送るコード量を減らすこと
- HTML と CSS を優先して使い、JavaScript 依存を最小化する
- React および類似フレームワークは、不必要なコード重複と性能低下の問題を引き起こす
では、代替は何か？
2つの問いに分かれる議論
- 狭い問い: 「クライアントレンダリングが必要な場合、React の代わりに何を使うべきか？」
- モダンなフレームワーク（例: Svelte, Lit, FAST, Solid, Qwik, Marko, HTMX, Vue, Stencil など）を検討する価値がある
- ただし、これらのフレームワークを使う場合でも、クライアントサイドのペイロードと複雑性を厳格に管理すべき。JavaScript は HTML/CSS と比べて少なくとも3倍以上コストが高い
- 広い問い: 「React に依存した技術スタックを全面的に見直すにはどうすべきか？」
- 単に新しいツールに置き換えるのではなく、既存アーキテクチャの目的と限界を理解し、再設計しなければならない
狭い問いへのアプローチ
- 小規模な PoC（Proof of Concept）を複数作成し、性能のスケーラビリティと限界を評価する
- このような客観的な実験は、チームメンバーに意味のあるエンジニアリング経験を提供する
広い問いを投げかけるチームに共通する状況
- React を置き換えようとする議論で混乱を感じることが多い
- 既存アーキテクチャをなぞる形で意思決定している場合がほとんど
- ユーザー体験に対する明確な理解と、データに基づく意思決定の欠如
フレームワーク主義とユーザー中心アプローチの違い
- フレームワーク主義: フレームワークにより多くの機能を追加すれば、あらゆる問題が解決すると信じること
- 実際には、ユーザーの問題を解決できない場合が多い
- 非定型パターンやデータ中心の証拠を無視する
- 現実主義: ユーザー体験を測定し、実データに基づいて意思決定する
- ユーザーの要求と制約条件を理解し、それに基づいて技術スタックを設計する
- 出発点は常にユーザー要件
現実主義を導入する方法
- RUM データ活用: Core Web Vitals のようなユーザー中心の性能指標を使う
- 性能テスト: WebPageTest（WPT）などのツールを活用し、主要ユーザージャーニー（critical user journeys）を測定する
- ビジネス目標とユーザー体験を結び付ける: データを通じて改善方向と投資対効果を評価する
データ駆動アプローチの重要性
- フレームワークを信頼ベースで採用するのではなく、データでその効果を検証する
- 流行に乗った技術採用の実際のコストと効果を比較する
- 測定可能な指標を通じて、ユーザー体験の最適化を重視した技術選定を促す
価値あるものは何ひとつ失われていない
React の拡散を防ぐ方針の効果
- React およびその他のフレームワーク中心アプローチを禁止することは、コスト削減とユーザー中心のチーム再編に寄与する
- しかし、フレームワーク主義を完全に排除しなければ、根本的な成果改善は難しい
- 1つの誤りを避けても、同じカテゴリの別の誤りに投資してしまえば、効果は限定的である
広い問題に対する一般的な解決策
ユーザー中心
- 意思決定者は、自らのエンジニアリング選択の結果に対して直接責任を負うべきである
- 言い訳の余地なく、システムがユーザー（特に取り残されがちなユーザー）に対してうまく機能しないなら、代替バージョンを導入する
- 解決すべき問題だけが存在し、既存方式を無条件に守る「聖域化」は排除する
証拠に基づくアプローチ
- 経営陣とエンジニアリングの間で共有された現実主義へのコミットメントが必要
- 意思決定では、より良い証拠が常に優先されるべきである
ガードレール
- フレームワーク主義の幻想的な主張を防ぐための方針が必要
- 例: 英国政府デジタルサービスのプログレッシブエンハンスメント技術要件
- 組織の状況に応じて方針は調整可能（例: 例外時のエスカレーション経路を作る）
- しかし重要なのは明確な基準設定。証拠ベースの方針は強い影響力を発揮する
技術の比較評価
- 明確に定義された**主要ユーザージャーニー（critical user journeys）**なしに新しいシステムをデプロイしてはならない
- 主要ユーザージャーニーとは、システム内でユーザーが最も頻繁に行う作業を表す
- これを基に、各技術の成果を制約条件の下でテストする**比較評価（bakeoffs）**を実施する
- プロダクトマネージャーは、ただ闇雲に実験を提案するのではなく、製品の明確な仮説を定義し、成功基準を設定すべきである
- これは不快なプロセスになり得るが、プロダクトマネージャーの中核的役割である
- それが自分の仕事に合わないと判断する PM の退職は受け入れる
ケーススタディ
現実主義とフレームワーク主義の違い: 事例で理解する
- 技術選定の基準
- 技術選定は、主要なデータ更新回数とセッション長を基準に評価する
- 一部のアプリクラスは、長いセッションと頻繁なデータ更新を特徴とする
- この場合、ローカルデータモデルが適している可能性がある
- しかしこれはまれな例外的状況に当たる
- 短いセッションの場合
- 平均セッション時間が短いサイトでは、初期 JavaScript 読み込み量を最小化しなければならない
- ほとんどのサイトは SPA アーキテクチャを必要としない
- SPA アーキテクチャが必要な場合
- SPA アーキテクチャは、特定条件を満たす場合にのみ検討すべき
- セッションが長く、同一データへの複数回更新が必要な場合
- この条件を満たさないサイトは SPA を採用すべきではない
- SPA アーキテクチャは、特定条件を満たす場合にのみ検討すべき
- 核心的な問い
- 選択は JavaScript フレームワーク同士の問題ではない
- 多くの場合、そもそも SPA 志向のツール自体を使うのが適切かどうかを判断することが核心である
- ほとんどのサイトでは、明確に**「ノー」**という答えになる
情報提供型Webサイト（Informational）
- 最適な構成: セマンティック HTML と、必要に応じたプログレッシブエンハンスメントの活用
- 静的サイトジェネレーター（Hugo, Astro, 11ty, Jekyll）が適している
- 頻繁に更新されるコンテンツには WordPress のような CMS ツールを使う
- ブログ、マーケティングサイト、企業ホームページ、公共情報サイトでは、クライアント JavaScript ペイロードを可能な限り減らすべき
- SPA アーキテクチャ向けに設計されたフレームワークを使うべきではない
- なぜセマンティックマークアップとプログレッシブエンハンスメントが適しているのか？
- 短いセッションとサーバー所有データモデルが特徴
- ページに表示されるデータの出所は常にサーバーで管理される
- クライアントデータモデルの抽象化やコンポーネント定義は不要
- CMS 構成:
- 執筆者向けの低トラフィック・高インタラクション編集UI
- 読者向けの高トラフィック・低インタラクション閲覧UI
- 短いセッションとサーバー所有データモデルが特徴
電子商取引（E-Commerce）
- 推奨アーキテクチャ: サーバー生成のセマンティック HTML とプログレッシブエンハンスメント
- Amazon と比べると、React ベース競合の性能差は明白
- Walmart トラフィックの70%以上がモバイル由来であり、SPA ベースの Next.js はビジネスに悪影響を与える
- プログレッシブエンハンスメントが適している理由
- 電子商取引の一般的構成:
- 提供中の商品と検索機能を含むランディングページ
- フィルターや比較機能を備えた検索結果ページ
- 商品詳細ページ: メディア、レビュー、代替提案を含む
- カート管理、決済、アカウント管理画面
- サーバー所有状態:
- 新鮮なコンテンツ（例: 価格）を維持する
- 軽量ページ最適化によってレイテンシを削減する
- 積極的なキャッシュ、画像最適化、ページサイズ削減戦略を使う
- 電子商取引の一般的構成:
メディア消費型Webサイト（Media）
- 基本構造: プログレッシブエンハンスメントを基盤として設計
- 必要に応じて製品変化に合わせて複雑性を追加する
- プログレッシブエンハンスメントと Islands 構造が適している理由
- コメントスレッドのような対話的要素は、独立したデータモデルとして構成可能
- Web Components を活用し、静的ページ内に実装できる
- SPA が適している場合
- メディア再生の持続性:
- ページ遷移中もミニプレーヤーを維持する必要がある
- SPA 技術の利用とクライアント JS サイズ制限の管理
- オフライン再生対応:
- ローカルメディアキャッシュを管理するロジックが必要
- Zero, Y.js のようなデータ同期システムを検討
- メディア再生の持続性:
ソーシャルメディア（Social）
- ハイブリッドモデル: サーバー所有データモデルに基づく少ないインタラクション + 断続的なメディア更新
- プログレッシブエンハンスメントが適している理由
- 一般的なインタラクション:
- 「いいね」のクリック、断続的な更新など
- Hotwire または HTMX を使ったハイブリッド方式が適している
- 一般的なインタラクション:
- SPA が適している場合
- 深いインタラクションの島:
- 下書き投稿の保存などでクライアントキャッシュを活用
- オフライン対応:
- HTML を優先配信しつつ、Service Worker による同期とオフラインロジックを実装
- 深いインタラクションの島:
生産性アプリ（Productivity）
- ドキュメント中心の生産性アプリは、複雑な要件（共同編集、オフライン対応、軽量閲覧モード）を持つ
- ローカルデータモデルと SPA ベースのアーキテクチャが適している場合がある
- SPA が適している理由
- 頻繁なデータ更新:
- キー入力、マウスドラッグのような操作ではクライアントロジックが優位
- 性能制約の管理が必要:
- 初期バンドルサイズの管理
- 遅延パッケージロード戦略の適用
- 頻繁なデータ更新:
その他のアプリケーションクラス（Other Application Classes）
- 特定要件:
- 3D CAD、プログラミングエディタ、ゲームストリーミング、Webベースゲーム、メディア編集、音楽制作システムなど
- 各アプリクラスは、生産性アプリと同様の形で慎重な評価が必要
- 成功要件:
- 主要ユーザージャーニーの定義
- 平均セッション深度の分析
- 性能保証指標の設定
- 重要スクリプトとリソースの制御
エンタープライズソフトウェアについて一言
- 「企業向け業務アプリ」は一般に最悪の性能問題を引き起こす
- ダッシュボード、ワークフローシステム、企業向けチャットアプリなどが代表例
- 性能は文化である:
- 初期ロード時間と操作後性能の定義・測定に失敗している
- ユーザーを無視する開発者中心文化が毒になる
「でも…」
- React を含む特定フレームワークに縛られた管理者は、しばしばそうした選択を正当化するためにさまざまな理屈を並べる
- しかし、これらの議論はユーザー体験を中心に据えておらず、その欠如は繰り返し表れる。
「…私たちは速く動かなければならない」
- 質問: 「それはどれくらい長続きすると思いますか？」
- 急いで作った NPM ベースのプロジェクトは、アクセシビリティ問題、低性能、複雑性の増大を招き、結果として速度は低下する。
- 是正コスト: JavaScript 問題の解決に数か月を要し、機能リリース速度はさらに落ちる。
- Product-Market Fit のためには、アクセシビリティと品質を優先すべきである。
- React を使って「速く動こう」とする選択は、長期的にはより高コストで成長を妨げる。
「…Facebookでうまく使っているじゃないか」
- ほとんどの企業はFacebook のような問題に直面していない。
- Facebook も React 利用による性能問題を抱えているが、独占的地位によってそれを覆い隠している。
- 一般企業はFacebook の事例をそのまま真似すべきではない。
「…うちのチームはすでに React を知っている」
- React 開発者は Web 開発者である。CSS、HTML、JavaScript、DOM の作業は必須だ。
- React は技術スタックの中で置き換え可能な最も単純な層である。
- Preact, Svelte, Lit, FAST などより小さく高速なフレームワークを学ぶ障壁は大きくない。
「…採用を楽にしたい」
- 現在の IT 業界は、優秀な開発者を採用できる絶好の機会である。
- React の知識は採用基準にはなりえない。
- React を知る開発者の多くは、Web 標準も容易に学べる。
- むしろ、より単純なシステムのほうが高い ROI をもたらす。
「…みんな速いスマホを使っている」
- モバイル利用が増えたこの10年間、クライアントリソースが安いという前提はすでに誤った仮定である。
- 低性能スマートフォンのユーザーも、製品の主要顧客である可能性が高い。
- React を選ぶことで、すべてのユーザーが高価なデバイスを使っていると仮定するのは危険である。
「…React は業界標準だ」
- React は一貫した標準ではない。
- React 自体の流儀（クラスコンポーネント vs 関数コンポーネント）、TypeScript の使用有無、状態管理ツールの選択など、プロジェクトごとに異なる。
- React スタックは常に流動的であり、「標準」という主張は心地よい虚構にすぎない。
「…エコシステム…」
- React 専用互換のライブラリは非常に少なく、ほとんどのツールは Preact などでも利用可能。
- あらゆる NPM パッケージは将来に対する技術的負債として作用する。
- CSS-in-JS のような不要な依存関係はコストを増やすだけである。
「…Next.js でも十分速い」
- Next.js は基本的にReact の性能問題をそのまま持ち込む。
- HTML 優先ツール（例: Astro, 11ty）は Next.js より優れた性能を提供する。
- VC 支援スタートアップの API にロックインされる問題もある。
「…React Native!」
- React Native はモバイルアプリを遅くし、保守に多大なコストを要する。
- PWA および Capacitor/Cordovaを使うほうがより良い選択である。
- Facebook も React Native から離れつつある。
12件のコメント
一般企業はFacebookの事例をやみくもに真似してはいけない。
性能の低いスマートフォンのユーザーも、製品の主要顧客である可能性が高い。
React Nativeはモバイルアプリを遅くし、保守に多くのコストを要求する。
ハハハハハハハ ハハハ
文章が長すぎて、主題意識がぼやけている。
筆者は、Reactを使おうという意見を無条件にフレームワーク至上主義に由来するもののように考えているように見える。
フレームワーク至上主義を離れてケースごとにアプローチしようと言いながら、あらゆる種類のエンジニアリング上のニーズについてレシピを作ろうとしている。
想定される反論のすべてに答えようとする、過剰な対話の占有の試みが目立つ。反論に対する再反論もあまりに偏狭だ。
つまり、特定のケースを超えて一般論を扱う議論を行うには、筆者の備えている議論の姿勢と技術は非常に不足しているように見える。
その結果、私はReactを使うことが好きではないにもかかわらず、筆者の一方的な態度だけのせいで、Reactの使用を主張する人たちの考えをもう少し聞いてみたくなった。
個人的には、現時点では React が最善だと思っているので、その前提で意見します。
Web 開発への入門は PHP と jQuery の時代からで、今働いている会社では AngularJS、Angular、クラススタイルの React、フックスタイルの React を経験してきた立場からすると、先に使った人たちの試行錯誤やライブラリが整ってから技術スタックを変えるほうが、頭を悩ませずに済みます。セマンティックバージョニングで言えば、最新バージョンより一つ下のメジャーバージョンを使うようなものです。要求事項や高水準の機能は変わらないので問題はないのですが、基盤技術に関する参考資料がないと生産性が出ないんですよね。また、うちの会社のプロジェクトの特性上、SaaS サービスと違って製品サイクルが長く、メンテナンスだけを行う期間もあるため、なおさら最新技術を適用しにくかったです。
おそらく React が Next.js へと方向転換し、SPA のサポートを終了してアーキテクチャ変更を強制するような時点になれば、もう一度技術転換を検討する必要がありそうです。Vue がもう少し普及していれば、候補には当然入れると思います。使わない理由はありません
モバイルアプリでRNが遅いと言うのに、なぜCapacitorやCordovaを勧めるのでしょうか？ 少なくともUIをネイティブで見せられるという点では、ハイブリッドWebよりはるかに性能面で優れたアプローチだと思います。
悲しいことに、韓国の採用市場では「フレームワーク原理主義は通用しない」と言ったら、面接であっさり落ちる可能性が非常に高いでしょう。多くの面接では、フレームワークを数多く使ってみて初めて分かるような質問をされます。
Reactでなければ、何を使う？
RN開発者、むせび泣く
まあ、まじめにコメントするなら、RNはJSバンドルでネイティブコンポーネントを扱えるようにすることに意味があるので、PWAとはユースケースがまったく違います。
WebViewでも扱いにくい部分があるのに、PWA？ 長期的にはその方向につながっていくとは思いますが、今はまだ時期尚早です。そもそも意味のない比較をしているように感じます。
そうですね。本文は、ほとんどネイティブアプリが不要だというレベルの意見ですね。
新しいものに惹かれる人がいる限り、このような問題は繰り返されるのでしょう。すでにReactで構築されたシステムがある以上、採用の問題を無視しても現実は変わらないはずです。FacebookがReactを推進していた理由と、10年が経って一般企業がReactを選ぶ理由には違いがあります
アーキテクチャやパラダイムを変えようという議論は、これよりも慎重であるべきで、できるだけ多くの人を説得する必要があると思います
でも preact も react ライクだし、react を離れるとライブラリの数が……
使えそうなライブラリはみんな react 専用に見えて、vue 開発者は泣きます
ちゃんと使えているのに、少し難癖をつけている感じがしなくもないですね……。こんなふうに長々と書かれると、何か大きな問題に直面したかのように受け取れ、という雰囲気を感じます……
Hacker Newsの意見
Reactを使うことに反対する理由の大半は、間違った問題を解決しようとしているものだと思う。パフォーマンスの問題は実際には大きな問題ではない。ほとんどの場合、バックエンドの改善のほうが効果的
ReactとjQueryが人気を得た理由は、コードがきれいに見えるから。AngularJS初期のコードサンプルは見栄えがよくない
Reactの核心は、O(n)のUI状態を関数型でレンダリングできるようにしたこと。昔はO(n^2)の状態遷移を管理するのが複雑だった
Reactを使い続ける理由は、Javaのように安定していて成熟した技術だから。コミュニティとリソースが豊富
Alexの記事は、繰り返される論争に対する苛立ちを示している。多くの人は記事を最後まで読まない
React開発者がWeb開発者だという言い方が、だんだん当てはまらなく感じる。SPA Reactとスタイリングフレームワークにしか慣れていない開発者が増えている
ほとんどのサイトにSPAは必要ない。しかし、多くのデータを必要とするビジネスではSPAが有利
Reactは好きではない。主にバックエンド開発者として、サーバー生成HTMLと少しのJavaScriptを好む
フロントエンド開発がJavaScriptフレームワークへ移っている理由は、保守コストのため
Reactに対する的外れな批判が多い。React開発者は新しいテンプレート言語を作らなくても作業を完了できる