React フレームワーク

• React
  • 問題：CSSやDOMのツリーの縦横が大きくなるにつれて、カスケード更新が大変になる
  • コードベース規模が肥大化した際におけるカスケード更新を簡単にできることを目的としたフレームワーク
  • カスケード更新：- データ変更があった場合親Nodeから子Nodeを順々に再描画
• Next.js(Page Router)が実装された理由
  • https://qiita.com/Yuki_Oshima/items/5c0dfd8f7af8fb76af8f
  • 目的：
    • SSRや静的サイト生成（SSG）が手軽に使える
      • SSR（リクエストごとに静的リソースを生成）→SSG（ビルド時に一度だけ生成）
      • リクエストまでページ内容が確定しないことは稀な為、SSGが主流になった
    • ファイルベースルーティング
      • Reactは疑似的にURLを書き換えて見かけ上のページ遷移を実現
        • react-router-domライブラリを使用→URLとコンポーネントの対応付けなどがやや面倒
      • ルーティングライブラリは不要で、URLの構造に合わせてjs(ts)ファイルを配置するだけ
    • 画像最適化
      • Next.js 10.0.0から専用の画像コンポーネントが追加され、配置されるサイズに応じて元画像をトリミングして配信
      • 必要なサイズのデータだけをダウンロードするので画像の表示を大幅に高速化
• Next.js(App Router)が実装された理由
  • Pages Routerの問題：ページの一部ではなく全体を返却するシステムだったため、Reactの基本構造とは離れた設計になっていた
  • https://www.northdetail.co.jp/blog/3480/
• Remix
  • 目的：廃れる可能性が少ない、Webの標準仕様となったものを最大限に活用したフレームワークを作ろう、ということで生まれたのがRemix
  • https://codezine.jp/article/detail/16642?p=3
• Svelte（Reactベースではない）
  • フレームワークだがコンパイラーであるという特異性
  • 実行前にコードを最適化したJavaScriptにコンパイルする = 軽い、速い
  • 少ないコード量で書ける、仮想DOM使わない
  • 業務上で記述量を減らすにはフレームワークよりは共通コンポーネントがあるかが重要
  • Reactの巨大なコミュニティを持っていることからくるアドバンテージにはまだまだ勝てない
  • https://qiita.com/dida_besar/items/6922af71c03315ef8993