Dan氏によるCreate React Appの将来、およびReactとフレームワークの関係性についてのコメントの翻訳

Create React App(以下「CRA」という)の将来、およびReactとフレームワークの関係性についてDan氏がGitHubのIssueのコメントで語った内容の翻訳です。非常に長いコメントですが、Reactユーザーであれば一読に値する内容だと思ったので翻訳してみました。参考になれば幸いです。

DeepLと筆者の英語力を元に翻訳しました。そのため、原文と解釈が異なる箇所があるかもしれませんが、ご容赦ください。コメントにて優しくご指摘頂ければ幸いです。

原文

https://github.com/reactjs/reactjs.org/pull/5487#issuecomment-1409720741

翻訳

みなさん、こんにちは。

CRAの現状については以前から痛いほどわかっており、それに対処するための提案に取り組んでいるところです。このプルリクエストは議論を始めることを目的にしていたので、私たちがCRAの将来について考えているいくつかの背景を説明する良い機会だと思います。私たちが考慮している理由とトレードオフについて明確にしたいので、いくつかのセクションからなる長いコメントになりそうです。もし全てを読む気になれないなら、最後のセクションまでスクロールして私たちが提案する今後の方法をご覧ください。

なぜCRAが存在するか

この議論の歴史的経緯を説明するために、まずはCRAのストーリーを振り返り、その進化を辿ってみたいと思います。

2016年にCRAをリリースした時、各ツールはばらばらで統合されていませんでした。既存のアプリにReactを追加する場合は<script>タグを追加するか、npmからインポートして、既存のビルドツールの設定を調整することになるでしょう。しかしスクラッチでReactだけで構築された新規のアプリを作成する場合は明確な方法がありませんでした。

CRAをリリースする以前は自分で一連のツールをインストールして、協調して動作するようにしなければなりませんでした。そこにはJSXを使うための正しいプリセットの設定や開発環境と本番環境で異なる設定、アセットのキャッシュのための正しい設定、linterの設定…などがありました。これを正しく行うのは非常に難しいことでした。そこでクローンできる「ボイラープレート」リポジトリを作成して共有することで対処しようとしましたが、それは別の問題を発生させることになりました。一度ボイラープレートをクローンして自分のプロジェクト用に調整すると、アップデートが難しくなったのです。自分のプロジェクトの設定が古くなると、アップデートを諦めるか、全てのツールが再び協調して動くようにするために多くの労力を費やすかのどちらかでした。変化の激しいエコシステムにおいて、これは非常に難しいことでした。

CRAは複数のツールを一つのパッケージにまとめることでこの問題を解決し、各ツール間のちょっとした非互換性を隠蔽しました。これで、Reactで新規のプロジェクトを始めたい場合の明確で推奨の方法が1つできました!そして、時々、このパッケージをアップデートすることで、「無料で」基本的なツールのアップデートを得ることができました。このモデルは非常に人気となり、今日ではこの方法で動作するツールのカテゴリが存在するほどです。Viteは同じようなビジョンを共有し、何らかの方法でそれをさらに推し進めた本当に最高のツールの一つです。

CRAの目標は大多数のReactユーザーが新規のReactのWebアプリを始めるための最適な方法を提供することでした。それは協調して動作する選別された機能群をサポートしました。時間が経つと、すぐに使えるものの「基準」は適切なトレードオフを見極めながら拡大していきました。例えば、実行時エラーのオーバレイが追加されました。異なるスタイリングのオプションのサポートが追加されました。デフォルトでFast Refreshが追加され、コンポーネントのコードを保存しても状態を失うことなく変更を確認できるようになりました。これはデフォルトのReactのDXのための大きなマイルストーンになりました。一般的に、CRAはコンパイルのパイプラインを完全にコントロールしていたので、コンパイル関連の機能の追加は誰でも簡単にできました。

このような選別されたセットアップを持っていることはエコシステムに貴重なものを残しています。React Hooksが登場した時、私たちはReact Hooksのlintルールをデフォルトのセットアップに追加しました。プロジェクトを始めるための簡単な方法であることに加え、CRAはReactチームが重要なツールの変更(Fast RefreshのサポートやReact Hooksのlintルール)を可能な限り多くのユーザーに展開することを可能にしました。Reactチームによって選別された定番のテンプレートがなければ、ツールの変更をこれほど広く展開することは難しかったでしょう。

CRAの問題

年月が経つにつれて、CRAは停滞してしまいました。多くの人がこのスレッドで、代替品より遅いこと、今日使いたいと思ういくつかの定番のツールをサポートしていないことを指摘しました。原理的にはこれらの問題を解決することができるでしょう。例えば、より速いバンドラーを使用するためにCRAの内部をアップデートすることができるでしょうし、内部的にViteを使用することでさえ可能でしょう。あるいは、CRAからViteのようなものへの移行を提案することもできるでしょう。しかし、私たちが解決したいのはもっと深い問題なのです。

設計上、CRAは純粋にクライアントサイドのアプリを作成します。これはCRAで作成された全てのアプリは空のHTMLファイルとReactとアプリケーションバンドルを含む<script>タグを含むことを意味します。空のHTMLファイルがロードされると、ブラウザーはReactのコードとアプリケーションバンドル全体がダウンロードされるのを待ちます。これは低帯域の接続ではしばらく時間がかかることがあり、この間ユーザーは何も映っていない画面を見ることになります。そして、アプリケーションコードがロードされます。今度はブラウザーがその全てを実行する必要があり、パワー不足のデバイスでは遅くなることがあります。最後に、この時点でユーザーは何かが写っている画面を見ることになります。しかし、たいてい何らかのデータをロードする必要もあります。そこで、コードは何らかのデータをロードするためのリクエストを送信し、ユーザーはレスポンスが返ってくるの待ちます。そしてとうとう、データがロードされ、コンポーネントはデータを伴って再レンダリングされ、ユーザーは最終的な結果を見ることになります。

これは非常に非効率ですが、クライアントサイドだけでReactを実行する場合はこれ以上良くすることは難しいでしょう。これをRailsのようなサーバーサイドフレームワークと比較してみましょう。サーバーはすぐにデータフェッチを始め、全てのデータを伴ったページを生成するでしょう。あるいは、Jekyllのような静的生成を行うフレームワークは同じことを行いますが、それはビルド中に、静的ホスティングサービスにデプロイできるHTMLとJSとCSSのバンドルを生成するでしょう。どちらのケースも、ユーザーはスクリプトのロードを待つ空のファイルの代わりに全ての情報を含むHTMLファイルを見ることになります。HTMLはWebの基本です。ではなぜ「Reactアプリ」を作ると空のHTMLが生成されるのでしょうか？なぜWebの最も基本的な機能の利点(全てのインタラクティブなコードがロードされる前に素早くコンテンツを見ることができる)を享受しないのでしょうか？なぜ全てのクライアントサイドのコードがロードし終わるまでデータをロードし始めないのでしょうか？

CRAは問題の一つの側面のみ解決しました。CRAは良い(その時点では!)DXを提供しましたが、良いUXのためにWebの長所にレバレッジをかける仕組みを提供しませんでした。ユーザー自身でこれらの問題を解決しようとしたかもしれませんが、それは「eject」と大幅なカスタマイズを伴うもので、CRAの利点を損なってしまいました。全ての真に効率的なReactのセットアップはカスタムされていて、異なっていて、CRAでは実現不可能なものでした。

こうしたUXの問題はCRAに限ったものではありませんし、Reactに限ったことでさえありません。例えば、PreactやVue、Lit、Svelte向けのViteのホームページのテンプレートで作成されたアプリは全ての同じ問題に悩まされています。これらの問題は静的サイト生成(SSG)やサーバーサイドレンダリング(SSR)を伴わない純粋にクライアントサイドのアプリに特有のものです。

Facebook.comのHack/XHPレンダリングからReactへの書き換えはSSR(結局パフォーマンスのために重要だった)なしで達成できなかったでしょうし、上記の問題はFacebookのような大規模アプリにのみ特有のものではありません。全く逆です!フルReactで開発された多くのアプリを考えてみると、SSGやSSRの恩恵を受ける種々のコンテンツ志向のアプリがあることがわかるでしょう。ポートフォリオやブログ、新聞、ECサイトでは空のHTMLファイルを提供することに単純に意味がないのです。そのためコンテンツ志向のサイトではSSG対応のReactフレームワークの使用を常に提案してきたのです。

Reactフレームワークの台頭

フルReactで構築しないほうがよいという人もいるかもしれませんし、それは有効な選択肢です。例えば、JekyllやAstroのような異なるツールを使用すればサーバーでビルド時にHTMLページを生成できるでしょう。これは空のHTMLファイルを返すという問題を解決しますが、二つのレンダリング技術を組み合わさなければなりません(例えば、ページの「外側」にはJekyllテンプレートが、「内側」にはReactコンポーネントが使用されるといったように)。インタラクティブ性を高めようとすればするほど、ますますこの技術的な分断は顕著になります。

この分断はDXを損なうだけでなく、UXも損います。真にHTML中心でReactの利点を完全に享受できないツールを使用すると、全てのページのナビゲーションはフルリロードになり、クライアントサイドの状態を吹き飛ばします。今日では、多くのユーザーは90年代のようなフルリロードよりむしろスムーズなアプリ内ナビゲーション(それが正しく、アクセシブルな方法で実行されることを前提に)を期待しています。同様に、多くの開発者は二つの異なるレンダリングモデルが混在しているより一つのレンダリングモデルを使用してアプリを構築することを好みます。皆Reactでアプリ全体を構築したいのです。そして、私たちはそれを可能にしたいのです。

Reactでアプリ全体を構築する場合、SSG/SSRを使用できることは重要です。CRAでそれらがサポートされていないのは明らかです。しかし、CRAが遅れをとっている分野はこれだけではありません。長年にわたるエコシステムのイノベーションの末に、その他多くの問題に対してReact向けの成熟した解決策が用意されています。例えば、ネットワークウォーターフォールやバンドルサイズが好例です。

たとえあなたのアプリがコンテンツ志向のサイトほどSSGやSSRの恩恵を受けないものだとしても、ネットワークウォーターフォールに悩まされる可能性は高いでしょう。「マウント時に」フェッチしている場合、初回のデータフェッチは全てのコードがロードされ、コンポーネントがレンダリングされてから実行されます。それがいわゆるウォーターフォールです。あなたのアプリがコードのロード中にフェッチし始める方法を「知っていた」場合はそれは並列に実行されるでしょう。ナビゲーションにおいて、親と子のコンポーネントの両方が何かをフェッチする必要がある場合、さらにひどいウォーターフォールが発生します。Reactのパフォーマンスについて語る際、多くのアプリにとってその事実から逃れることはできません。これらのウォーターフォールを解決するにはルーティングとデータフェッチを統合する必要がありますが、CRAはこれを行いません。

バンドルサイズが固定されているReactとは異なり、あなたのアプリケーションコードは新しい機能と依存関係を追加するたびに増え続けます。頻繁にデプロイする場合、常に全てのコードをロードしなければならないのであなたのアプリのロードは使用するたびに非常に遅くなります。この問題を解決する方法はいくつかあります。機能追加に対して「ノー」ということはできるでしょうが、これは常にうまくいくわけではありません。いくつかのコードをサーバーやビルド時に実行するように移動できるでしょう(ツールが対応している場合)。理想的なのはルートごとにコードを分割することです。ダッシュボードページがチャートをレンダリングする必要がある場合、アカウント課金ページではそのチャート全体の実装をロードする必要はありません。しかし、自前でコード分割をしようとすると、たいていパフォーマンスを悪化させてしまうでしょう。例えば、チャートを遅延ロードする場合、チャートは「マウント時に」データをロードしますが、また新たなネットワークウォーターフォールが発生してしまいます。これを上手く解決するにはルーティングとデータフェッチに加えてバンドルの統合が必要ですが、CRAはこれを行いません。

React自体はあくまでライブラリです。ルーティングやデータフェッチの方法の面倒は見ません。CRAも同様です。残念ながら、このことは本来の設計ではReact単体でもCRAでもこれらの問題を解決できないことを意味します。ご覧の通り、これは単に一つの機能が足りないということではありません。サーバーサイドレンダリングや静的生成、データフェッチ、バンドル、ルーティングといった機能が相互に関連しています。CRAが登場した当時、Reactは非常に新しいものであり、これらの機能をどのように組み合わせるかはもちろん、それぞれの機能が単独で動作するかについてもまだわからないことが多くありました。

時代は変わりました。今ではこれらの機能を持たないことにロックインされる解決策を勧めることはますます難しくなってきています。たとえこれらの機能全てがすぐに必要でないとしても、これらの機能が必要になった時に利用可能であるべきです。これらの機能の恩恵を得るために、異なるテンプレートへ乗り換えなければならなかったり、コードの全てを再構築しなければならなかったりするのはおかしな話です。同様に、全てのデータフェッチやコード分割がルートベースである必要はありません。しかし、ほとんどのReactアプリで利用可能であるはずの良いデフォルトです。

これらのピースを全て自分で統合することもできるかもしれませんが、上手くやるのは難しいです。CRA自体がコンパイルに関連するいくつかの問題を統合した時のように、Next.jsやGatsby、Remixのようなツールはさらに進んで、レンダリングやルーティング、データフェッチとコンパイルを統合しました。レンダリングやルーティング、データフェッチとコンパイルを統合したこの種のツールは「フレームワーク」と呼ばれています(もしくは、React自体をフレームワークと呼ぶのがお好きなら、「メタフレームワーク」と呼ぶかもしれません)。これらのフレームワークはより良いUXを提供するためにアプリの構造にいくつかの制約を課しています。多くの開発者もまたルーティングやデータフェッチのために奨励されているスケーラブルなビルトインの解決策が人間工学に基づいたものであるとわかっています。

アーキテクチャとしてのReact

私たちはReactの柔軟性が好きです。一つのボタンを構築するためにReactを使用することができますし、アプリ全体を構築するためにReactを使用することもできます。20年もののPerlのWebサイト内に内部ダッシュボードを構築するのに使用することもできますし、全部ReactでSSG/SSRハイブリッドのECサイトを作成することもできます。この柔軟性は必要不可欠なものであり、ユーザーもそれを望んでいることを知っています。これからもこの柔軟性は失われることはないでしょう。

しかし、Reactで完全に構築された新しいアプリに対して可能な限り最高のデフォルトを奨励したいとも考えています。SSGやSSR、自動コード分割、クライアント・サーバーウォータフォールの防止、ルートのプリフェッチ、クライアントのUIを保持したナビゲーション、など優れたUXを実現するその他の機能をサポートしたReactアプリを作成するためのデフォルトで推奨の方法があれば素晴らしいでしょう。少なくとも、Reactアプリを作成するためのデフォルトで推奨の方法は、これらの機能を有効にするための適切な懸念を統合していない元々クライアント専用のアーキテクチャが原因で、これらの機能を完全に締め出すべきではありません。

これはチャンスです。フレームワークにとって、これらの懸念と優れたパフォーマンスと人間工学を統合することは挑戦です。しかし、そこにはまたReactにとっての挑戦もありました。Reactフレームワークが優れたUXを届けるために私たちが彼らを助けることができる最善の方法はReact自体の基本的でプリミティブな機能にフォーカスすることだと気づいたのです。React自体がレンダリングレイヤーでできるユニークなことがあり、それはフレームワークが他の全てのレイヤーでできることを後押しします。例えば、<Suspense>のように、一つのReactのAPIがフレームワークの裏に潜む非常に様々なフレームワークの最適化の鍵になります。

そのため、Reactを二つの側面を持つと考えることが有効だと考えています。

Reactはライブラリです。このライブラリはコンポーネントを定義し組み合わせるいくつかのAPIを提供します。Reactはまたアーキテクチャでもあります。フレークワークの作者がReactのレンダリングモデルを最大限に活用できるような構成要素を提供します。フレームワークなしでReactを使用することはできます。しかし、フレームワークと一緒にReactを使う場合、フレームワークがReact自体の良さを最大限に発揮できることに気をつけてください。過去数年の間に構築してきた機能の多く(<Suspense>やuseTransition、renderToPipeableStreamのようなStreaming API、実験的なServer Components)はフレームワーク志向のものです。それらの機能はバンドルやルーティング、データフェッチと統合されることでフレームワークがReactの良さを最大限に発揮できるようにします。

Next.js 13やGatsby 5、Remix1.11に組み込まれているいくつかのこれらの機能を既に見ることができます。まだやるべきことはたくさんありますし、中には実験段階を脱したばかりのものもいくつかあります(そのため、ドキュメントも未整備です)。それでも、私たちの数年に渡る努力が実を結び、Reactのフレームワーク(とそのユーザー)がデフォルトでより高速なアプリを提供することができるようになることを嬉しく思います。

そこで、次のポイントになります。

一つのライブラリ、多くのフレームワーク

Reactのフレームワークは一つではありません。そして、それは良いことです。

乗り換えの懸念にもかかわらず、Reactのエコシステムは多くのプレイヤーがいることでより良いものになっています。複数の競合するデータフェッチの解決策とルーティングの解決策があります。選択肢は年々充実しています。ルーティングとデータフェッチ、レンダリング、コンパイルを統合する複数の解決策、つまり複数のReactのフレームワークがあることも驚くべきことではありません。

そのままの状況を保ちたいと思っています。しかし、それが可能であり、Reactのエコシステムに恩恵をもたらす場合は特定の解決策に収束することを奨励したいとも思っています。例えば、異なるフレームワークが異なる仕組みでデータをロードするかもしれません。しかし、ローディング中の表示のために<Suspense>を採用する場合、<Suspense>上の上位の機能は全てのフレームワークで動作するでしょう。フレームワーク向けにAPIを確定し、ドキュメント化する作業はまだ続きますが、フレームワークがReactを最大限活かすことができるようにしたいと考えています。

プロジェクトによっては人気のあるフレームワークの型にはまらないものもありますが、それはそれでいいのです。例えば、PHPサイトと統合する必要がある内部のダッシュボードを開発している場合、それを簡単に行うことができるフレームワークはありません。それはParcelのような低レベルのツールや純粋にクライアントサイドのViteテンプレートに最適なユースケースです。あなたのアプリはドローイングエディタで、ルートを持たず、SSGさえもオプトアウトしたいかもしれません。私たちはそれを常にサポートしてきましたし、今後もそうするつもりです。フレームワークのアーキテクチャとしてよりもむしろライブラリとしてReactを使用し続けることは有効です。私たちはそれがほとんどの新規のWebアプリにとって適切なデフォルトではないと主張しているだけです。

ほとんどのReactアプリにとって最善の方法はフレームワークを使用して始めることだとしたら、どのフレームワークを推奨するべきでしょうか？どれを選ぶべきでしょうか？どのように決定すべきでしょうか？時間が経って停滞してしまったらどうしますか？また、インセンティブという、よりセンシティブな問題もあります。人気があり活発にメンテナンスされているフレームワークには、しばしば、直接的、もしくは間接的に何らかの商業的な提供者が関係していることがあります。これらの提供者はそれらのフレームワークの開発に資金を提供することがあるかもしれませんが、例えば、特定のホスティングプラットフォームでしか動かないようなプロダクトを押し付けるようなことは避けたいと考えています。

そこで、このスレッドでの質問になります。

CRAはどうあるべきか？

CRAの元々の目標は以下の3つでした。

• 設定なしで新規のReactプロジェクトを始めるための簡単な方法を提供する
• コンパイル関連の依存関係を統合し、簡単にアップデートできるようにする
• Reactチームがツールのアップデートをできるだけ広く展開できるようにする(例えば、Fast RefreshやHooksのlintルール)

しかし、Reactアプリを作成するための最善の方法という元々の目標にはもう合致しません。コンパイルをレンダリングやルーティング、データフェッチと統合することで、フレームワークはユーザーに以下の3つのようなReactアプリを作成することができるようにします。

• 規模の大小に関わらず、デフォルトで高速なアプリとサイトを届けるためにWeb APIを最大限に活かす
• React自体とフレームワークレベルの機能を最大限に活かす
• 開発者を「成功の落とし穴」に落とすようなルーティングやデータフェッチを提供する

ReactのエコシステムはWebとReact自体を最大限に活かすことができるデフォルトで推奨の手法に値します。これは必ずしもNode.jsサーバーに依存するという意味ではありません。多くの人気のあるフレームワークはサーバーを必要としていませんし、SSGモードで動作することができるので、「完全に静的な」ユースケースにも対応できます。そのようなフレームワークの利点は、後からSSRが必要になった場合、移行する必要がないことです。SSRはその他のものと同様に利用可能です(例えば、Remixはすぐに使えるミューテーションのAPIを提供します)。

どのようにこのビジョンを達成すればよいでしょうか？いくつかの選択肢があります。

選択肢1: スクラッチで新しいフレームワークを作成する

データフェッチとルーティング、バンドル、SSG/SSRを統合するフレームワークとしてのCRAを再構築を試みることができるでしょう。これらの問題の交差する地点に高品質の新しいフレームワークを構築することは巨大な事業であり、多くの特定のエコシステムの専門知識を必要とし、これを成し遂げるためにその他のプロジェクトを止めたとしても、CRA自体がそうだったように時間が経つにつれて停滞するリスクが非常に大きいでしょう。また、実際のユーザーがいないにもかかわらず、公式に推奨されるフレームワークがもう一つ増えることで、エコシステムはさらに分断されるでしょう。私たちはこの選択肢は現時点で現実的ではないと考えています。

選択肢2: CRAを非推奨にして、Viteのテンプレートをメンテナンスする

CRAを非推奨にして、代わりに私たち自身のViteのテンプレートをメンテナンスすることができるでしょう。掲げた目標を達成するために、このテンプレートは非常に洗練されたものでなければならないでしょう。実際、Reactのフレームワークのように洗練されたものでなければならず、ルーティングやデータフェッチなどの意見も課さなければならないでしょう。そうなると、もう一つのフレームワークを作ることと同義になります。

選択肢3: CRAを非推奨にして、Reactのフレームワークを提案する

ツールとしてのCRAを強調しない、もしくは非推奨にして、より活発にReactのフレームワークを強調することができるでしょう。これはReactでフレームワークを使用しなければならないということではありませんが、ほとんどのアプリに対して何らかのフレームワークを使用することを提案することになります。デメリットはReactのアプリを作成するための中立的でブランドのあるCLI「ゲートウェイ」がなくなってしまうことです。対応するフレームワークのドキュメントで適切なものを見つけなければなりません。また、完全な廃止は混乱ももたらします。しばらくの間、コマンドを動作させ続ける必要がありますが、ブランディングの観点からは混乱をもたらします(「なぜReactのアプリを作成することが非推奨なのか？」)。

選択肢4: CRAに一つのフレームワークを使用させる

一つの指定のフレームワークを選んで、CRAがデフォルトでそのフレームワークでアプリを作成するように変更することができるでしょう。この手法の主な問題点はその他の解決策が競争することが非常に難しくなってしまうことです。特に、トレードオフが僅かに異なるものの、人気や機能群、品質の面ではほとんど同じである場合はなおさらです。また、このような動作の変更は、全ての古いチュートリアルがよくわからない形で壊れることが予想されるので、非常に破壊的なものでなければならないでしょう。

選択肢5: CRAをランチャーにする

コマンドとしてCRAは残しつつ、ランチャーにすることができるでしょう。推奨のフレームワークの一覧を提案し、最後の選択肢として「古典的な」フレームワークレスの手法を提案するでしょう。最後の「古典的な」手法は現在のCRAのようにクライアントのみのアプリを作成します(チュートリアルの破壊を避けるため)が、最終的にはViteの内部に移行することができるでしょう。

選別されたフレークワークの一覧に載るには、Reactのフレームワークは一定の基準を満たす必要があるでしょう。それはこのドキュメントページで事実上起こっていることに似ています。コミュニティでの人気や採用状況(一覧を短くするため)、機能群、パフォーマンス特性、WebプラットフォームやReact自体を最大限活かす能力、活発にメンテナンスされているか、さまざまなホスティングサービスや環境でホストする方法が明確であるか(ベンダーロックインを避けるため)を考慮する必要があるでしょう。各フレームワークのスターターテンプレートはReactチームによってメンテナンスされ、一貫した設計とブランディング、商用サービスとの繋がりがないこと、同様の構造であることを保証します。私たちがどのようにその選択に至ったのかについてコミュニティと明確にコミュニケーションする必要があるでしょうし、定期的にそれらを再評価することも必要でしょう。

私たちの提案

私たちは現在選択肢5(「CRAをランチャーにする」)に傾いています。 CRAの元々の目標は大半のReactのユーザーが新規のReactのWebアプリを始めるための最善の方法を提供することでした。ランチャーとして再利用することで、ほとんどの新規のWebアプリにとって最善だと考えているものを明確に伝えると同時に、古いフレームワークに対してエスケープハッチを用意しているところが気に入っています。選択肢3とは異なり、「Reactのアプリを作成すること」が何らかの形で非推奨であるという認識を避けることができます。多少の選択が必要ですが、現在は本当に素晴らしい選択肢があるという現実を認めているのです。

私たちはこれらの点を具体化するより詳細なRFC提案に取り組んでいく予定です。それまでの間、これらの点についてぜひフィードバックをお聞かせください。長いコメントになってしまいましたが、思考プロセスの全体像をお見せしたかったのと、この機会にReactとフレームワークの関係性を明確にしたかったのです。フォローアップの質問にはなるべくここでお答えしたいと思っています。

お読みいただきありがとうございました!