アルゴリズムの基礎が比較的弱く、何度も試行してやっと通過しました～
- React は早期にリリースされたため、一定の優位性を持ち、標準となりましたが、敏捷性と適応性においては深刻な欠点もあります。2013 年以降のすべての決定は別の技術的負債であり、競合製品にはこれらの制約がありません。
- エコシステムに関する問題：私たちは「トレーニング」されて、パッケージはフレームワーク特有のものであると考えています。React はこの見解を加速させ、何をするにも React のパッケージを見つけることになり、ネイティブ JS パッケージではなくなりました。そのため、React のルール、状態管理、コンポーネントのライフサイクルなどが持ち込まれ、これに適合しないものはあまり機能しないか、便利ではありません。しかし、そうあるべきではなく、すべては JS であり、JS のものであればすべてを取り入れるべきです。（もちろん Svelte や Vue などのフレームワークにも当てはまりますが、React はこの点で最も重いものであり、他のフレームワークは適応性が高く、レンダリングライフサイクルのような問題はありません。これらのフレームワークの共通の選択は Web コンポーネントを使用することです。）Preact の Signal はその一例であり、彼自身のために作られたものであるにもかかわらず、他のフレームワークやネイティブ JS でも使用できます。Web コンポーネントも同様で、非 React フレームワークに互換性があります。
- React Hooks は時代遅れです：Hooks はもはや優位性ではなく、基準、一般的な方法です。他のフレームワークにも似たようなものがありますが、より速く、使いやすく、書きやすいです。
- 微細なレベルでレンダリングを管理する必要はありません：例えば
useMemoとuseCallbackの違いや、useEffectの依存関係とライフサイクルの理解などです。他のフレームワークではこれらを気にする必要がなく、より賢く、値を更新するだけで、更新する必要のないものを持続的に更新することはありません。 - 大規模で複雑なアプリケーションを扱うことはもはや必要な関心事ではありません：React はフロントエンドが大規模で複雑なアプリケーションに対処するための最良、唯一、または最初の解決策ではなく、同じパラダイムの多くの可能なバージョンの一つであり、古いバージョンです。他の現代の競合フレームワークも同様にこの問題に対処できます。
- サーバーサイドレンダリングは特別ではありません：React 以外のほとんどのプレイヤーもサーバーサイドレンダリングをサポートしています。
- 双方向データバインディングは難しくも悪くもありません：React は単方向データフローであるため、フォームの使用が非常に面倒です。双方向データフローにはこれらの問題がなく、双方向データフローによって生じるいくつかの問題は長期間の反復の中で解決されました。
- スタイルの処理は非常に簡単です：React のスタイルには優雅な組み込みの解決策がありませんが、Vue や Svelte ではこの問題が組み込みで解決されており、コンポーネントレベルの作用があり、React で使える解決策もそれらで互換性があります。
- フレームワークはもはやそれほど難しくありません：React の状態管理、プロパティ、ネスト、ライフサイクル、hooks、JSX は、学ぶのがあまり親切ではありません。今の新しいフレームワークはずっと簡単に学べるようになっています。
- 著者は Svelte と Vue の二つのコンパイル時フレームワークを高く評価しています。
T：CodeBox
ChatGPT コードインタープリターを実現するための隔離された Python サンドボックス実行環境です。
S：読書《最高学以致用法》 のいくつかの記憶
出力と入力の時間比は 70% 対 30% に制御するのが最良で、出力が「有効な」学習であり、入力だけでは学んだことにはならず、記憶にも残りません。
Reference: