Reactアプリケーションの作成を開始するたびに、何らかの形でオプションを選択します。

• 前のプロジェクトのコピーアンドペースト
• ある種のボイラープレートまたはジェネレーター（ヨーマンなど）
• 構成を必要としない既製のフレームワーク
• すべてをゼロから自分で書きます

それぞれの方法には、長距離と短距離の両方で、独自の長所と短所があります。

一部のソリューションは、最初は複雑さを隠し、すぐに開始できるようにします。 これはターンキーソリューションのようなものですが、結果として、そのようなソリューションは十分な柔軟性がなく、微調整が難しい場合があります。 一方、最初はすべてが少し怪しくて遅いように思えるかもしれません。開始するには少し手を加える必要がありますが、その利点は明らかになります。 常にすべてを最初からやり直す機会がありますが、この場合は無数の側面を担当し、関連するすべての技術に関する非常に深い知識が必要になります。

明らかに、複数のプロジェクトの開発に関しては、社内に特定の標準があることは非常に有用であるため、どのチームでも任意のプロジェクトに切り替えることができます。 または、常に新しいプロジェクトを作成しているデザインスタジオの場合。 この場合、フレームワークの作成にかかる時間はできるだけ短くする必要があります。 共通の標準アプローチにより、チームと開発者は知識を共有でき、標準ソリューション、ベストプラクティスなどの特定のベースを維持できます。

市場分析では、Reactでサイトを作成するためのインフラストラクチャを提供するいくつかのかなり安定したプロジェクトがあることが示されています。 明確にするために、すべての候補者が可能な限り異なる性質を持つように、それらのいくつかを選択しました。

候補者

• Zeit Next.js （私は別に記事を書きました）Next.JS + Reduxで同形/ユニバーサルアプリケーションを作成します
• ウォルマートラボ電極
• Facebook Create React App （+カスタムソリューションの一部）
• たとえば、私の記事「 React + Router + Redux + Expressでのユニバーサル/同形アプリケーションの簡素化」のカスタマイズ
  
  
  • 構築するWebpack +設定を容易にするWebpackブロック
  • ExpressJSサーバー
  • 状態管理のリデュース
  • コードの構造化とナビゲーションのためのReact Router
  • サーバーレンダリングですべてをリンクするためのReact Serverを作成する

最新のアプリケーションを開発するときに覚えておく必要があること

キャッシュ可能なパーツ

アプリケーション全体を1つの巨大なJSファイルに収集すると、ユーザーはロードアニメーションを視聴しながら、永久にロードされます。 調査によると、ユーザーは3秒でロードする時間がないサイトを離れることを好みます。

• Next.jsは、ページごとに個別のチャンクを自動的に作成します
• 電極 、 Reactアプリの作成 、Reactルーターのカスタム使用。 Webpackには、コード分割と呼ばれるものがあり、React Routerでうまく機能します。 ところで、 Webpack 2では動的import()
  
  
  
  サポートされるようになりました 。 まだWebpack 1.x に座っている人には、解決策もあります 。 電極には、解決策として特別な原型があります。

静的管理

一方で、アプリケーションは、リソース（画像、スタイル、スクリプト）のためにネットワークを再度巡回しないように、可能な限りすぐに配信する必要があります。たとえば、 すべてのライブラリ、重要なCSSスクリプトを含むベンダーチャンク。 しかし同時に、このページで必要なものだけをできるだけ配信したいと思います。

• React Appの作成ではWebpackの構成を変更できないため、ここにスパンを示します
• Next.js 、 電極 、およびカスタムを使用すると、Webpackの設定を変更して、プラグインを介して取得する内容を変更できます

サーバー側のレンダリング

アプリケーションは必要なすべてのデータをダウンロードし、既成のHTMLを生成できます。このHTMLはデータとともにクライアントに送信されるため、最初のダウンロードと、少なくとも表示のために少なくとも何かがサイトに表示される瞬間との間の遅延が実質的になくなります。 これをすべて使用する機会については話していません。これは別の問題です。

Googleは、応答時間を含むサイトをランク付けします。 検索エンジンはAJAXサイトをレンダリングできるという事実にもかかわらず、これは位置に悪い影響を与えるため、サイトは検索エンジンが消化できるバージョンを提供する必要があります。 これには問題があります。メインコンテンツ領域だけでなく、すべてのデータをダウンロードする場合、すべてのダウンロードが終了したことをサーバーレンダラーに明確にする方法はありますか。 これに対する確立されたアプローチはまだありません。 カスタムバージョンでは、コンポーネントツリーを解析して、たとえば静的メソッドgetInitialProps



（ getInitialProps



類似）などからそれぞれを引き出し、これらすべてのメソッドが値を返すと、レンダリングできます。

• Create React Appはサーバーレンダリングのトレーニングを受けておらず、学習することはほとんどありません
• Next.jsとElectrodeにはこの主な機能があります
• すべてをゼロから構築する場合（つまり、 カスタム ）、これも構築する必要があります

コンポーネント自体がデータから必要なものを言うことができるようにするために、Relay + GraphQLが発明されましたが、短所はその利点を上回ります。 別のサーバーが必要です。 それは非常に冗長です（スキーム自体+突然変異は非常に面倒です）。 最も単純なアクションのために記述する必要があるコードの複雑さは、ほとんどすべてのボーナスを殺します。 これをチームの誰かにゼロから説明することも問題です。 さらに、特別なBabelトランスフォームと、回路をダウンロードしてコンパイルするためのユーティリティが必要になります。 その結果、SEOと互換性のないものが得られます。 既存のGraphQL APIのみを使用する場合、状況はわずかに改善されることを認識する価値があります。 これは非常に有望な技術です。私はみんながそれをより友好的にすることをなんとかしてくれると信じたいです。 また、Apolloフレームワークのようなものに注目する価値があります。

調査中に、サーバーサイドレンダリングに役立つライブラリをいくつか作成しました。

• React Serverの作成 （ カスタム用 ）
• Next.jsとRedux

サーバー側のレンダリングパフォーマンス

ある時点で、サーバーのパフォーマンスはコンポーネントのレンダリングに十分ではなくなります。 この場合、一部のコンポーネントはキャッシュを開始できます。

• 電極にはプラグインがあり、戦闘モードでは、すべてのコードはプリコンパイルされたファイルから取得されます
• Next.jsはまだこれに対して何も提供していませんが、コードはコンパイルして全体を保存します
• カスタムソリューションでは、いつものように、すべてを自分で行う必要があります。たとえば、 Create React Serverを使用してプロセスを簡素化する方法がありますが、サーバーのコンパイル済みコードの保存は制御しません。
• React Appサーバーレンダリングの作成にはありません

CSSプリプロセッサ

多くの人がLESS / SASS / Stylus / PostCSSを使用してスタイルで変数とミックスインを使用するため、コードはより簡潔で簡潔になります。

• ElectrodeとNext.jsはこのために何も提供しません。Webpack構成をカスタマイズできますが、これは推奨されません
• Create React Appはまったくサポートしておらず、説明もあります（TL、DRは構成を使用します）
• カスタムプロジェクトでは、通常のWebpackローダーを使用できます

どの候補でも、Create React Appのように、SASS / LESSスタイルの背後にある個別のビルド/監視プロセスをいつでも作成できますが、結果のCSSを手でアプリケーションに接続する必要があります（Create React Appに直接インポートできます）。 この場合、クリティカルCSSとホットモジュールのリロード、およびサーバー側のレンダリングスタイルが懸念事項となり、非カスタムソリューションの利点がなくなります。

サードパーティのUIライブラリとの統合

明らかに、インターフェイスに最適なライブラリを使用することで、特にTwitter BootstrapやMaterial Designなどについて話している場合、製品の外観を改善し、作成を加速します。 通常、これらのライブラリにはCSSがバンドルされており、CSSはアプリケーションに何らかの形で含める必要があります。

• Next.jsでは 、 _document.js
  
  
  
  （メインテンプレート）でスタイルを直接接続できますが、 _document.js
  
  
  
  はstatic
  
  
  
  ディレクトリに配置する必要がありstatic
  
  
  
  。 プリプロセッサを使用する場合は、スタイルを使用して他のファイルの下からCSSを含めることをお勧めします（カスタム_document
  
  
  
  とコレクターまたはカスタムWebpack _document
  
  
  
  を介して既に接続できます）。
• 電極を使用すると、CSSを直接​​インポートできます。 カスタムHTMLテンプレートを使用することもできます（ただし、ビルドに再度含める必要があります）。 または再びカスタムwebpackローダー
• Reactアプリの作成で CSSインポートが可能

クリティカルCSS /折り畳まれたCSS

大まかに言って、特定のスタイルにはHTMLをロードできるため、ユーザーはいわゆるいわゆるスタイルを見ることができません。 不安定なコンテンツのフラッシュ（FOUC）。 有用ですが、まったく重要ではありません。 現代のネットワークは非常に生産的で、最大100 KBのスタイルシートはまったくありません。

• 電極には特別なプラグインがあります
• Next.jsはJSXでCSSを使用するため、CSSは常にコンポーネントに直接含まれます。
• 残りについては、独自の何かを作成できます

スキンのサポート

これは誰もが必要とするわけではないまれなケースですが、多くのアプリケーションは異なるブランドまたはユーザーの利便性のために異なるスキンをサポートしています（たとえば、濃い色や明るい色など）。

• Next.jsはJSでCSSを使用するため、JSアプローチを使用して、CSSの関数を作成し、変数のスタイルを設定し、変数自体を引数として取得できます。
• 電極は変数のないCSSモジュールを使用します
• ビルドプロシージャでCSSプリプロセッサを使用する場合、基本スタイルに変数を入力し、異なる変数オーバーライドで複数の入力ポイントを作成し、アプリケーションにポイントの1つを含めることができます（たとえば、Twitter Bootstrapはこのように機能します）

生態系とコミュニティ

適切に設計および文書化されたエコシステム内に住むことは、小さなライブラリの山を理解するよりも常に優れています。依存関係の混乱が少なく、著者によって与えられた指示に従う能力、例の山です。 フレームワークを使用しない場合、最終的には自分でフレームワークを作成するというフレーズを覚えています。

• Electrodeは 、Githubに500個の星を獲得しています。GithubはStackOverflowのチケットや質問に答えるアクティブなコミュニティです。 ドキュメントは乱雑で非常に明確ではなく、非常に肥大化した例がありますが、見れば、あなたは生きることができます。
• Next.jsには Githubに〜9000個の星があり、プルリクエストとチケットに対する超高速応答です。 単純なケースと複雑なケースのドキュメントがあり、あらゆる場合に膨大な数の例があります。
• Create Reactアプリは 、Githubで最大21.500個の星を獲得しており、最大のコミュニティです。 フレームワーク自体は非常に小さく、原始的であるため、そこに文書化することすらありませんが、著者は多くの例とレシピを書くことができました。
• カスタムアプリケーションでは、自分自身で、すべての例、ドキュメント、コミュニティがインターネット中に散らばっています。すべてを探し、自分でスマートソリューションを選択する必要があり、知識の唯一のキャリアを取得する必要がありますが、これは会社にとって非常に悪いことです。 ドキュメントを自分で作成する必要があります。

テスト

テストのない現代の世界では、誰もそれを議論する人はいないと思います。

• Electrodeは、PhantomJSを使用して、正直なブラウザーテストと個別のサーバーテストを行います。これは、可能な限り最高のカバレッジです。
• Create React AppにはJestが付属していますが、それは良いことですが、ブラウザーで実行されないため、公平な報道ではありません
• Next.jsとカスタムの場合、すべてを自分で行います

定型、構成、初期費用

1つの標準に基づいて多くのプロジェクトを行う予定であるため、ソリューションの初期セットアップと立ち上げに伴うトラブルをできる限り少なくしたいと考えています。 このため、初期化で生成されるファイルと構成はできる限り少なくすることが望ましいです。

• Next.jsとCreate React Appは設定なしで完全に動作し、必要なファイルを契約に従って分解するだけで、すべてが魔法のように動作します
• ElectrodeにはYeoman用のジェネレーターが付属しており、巨大なファイルの山を生成するだけなので、何に慣れるかに時間を費やす必要があります。 この山には文字通りすべてのものがあります：構成、サーバーコード、サーバーページのコード、クライアントコード。これまでのところ、少なくとも何らかの形で最適化する方法を見つけていません。
• カスタムには、除去できない一定量のコードが常にあります。 しかし、数十のプロジェクトを実行している場合、ある時点で、抽象化に移動できる繰り返しパターンが必要になります。 そして、それはオープンソートさえすることができます;）。 正直なところ、これはElectrodeでも行うことができ、彼ら自身がこれに来るように思えます。

開始時の学習曲線、難しい場合、カスタマイズの難しさ、将来のサポート

チームの一部としてアプリケーションを使用するとします。その場合、何らかの方法で同僚を訓練する必要があります。 ドキュメントと固定パターンは、チーム内およびチーム間で知識を簡単に共有するための優れた基盤です。

何かをカスタマイズする機能も必要です。 私たちは現実の生活を営んでおり、いつでも何でも変更できます。要件は永遠ではありません。 そして、私は本当にフレームワークのある種の厳格な制限に遭遇したくありません。

• Reactアプリの作成は、最初は最も簡単に理解できますが、通常は変更する手段を提供しません。 そのソースコードは非常に厳しいため、「イジェクト」を行う（つまり、アセンブリ用のすべてのスクリプト、すべての構成、およびその他のガットを削除する）場合は、カスタムを優先してこの方向を直ちに放棄することをお勧めします。 パッケージにはリンターが含まれています。 APIはまったくなく、契約の数は最小限なので、アップグレードは簡単です。
• Next.jsはいくつかの側面を処理します。これを行う方法を理解するには少し時間がかかります。 ほとんどの単純なケースには例がありますが、複雑なものや非標準のものが必要な場合は、自分で撮影する方が簡単で、コードが混乱し、多くの不安定なサードパーティのソリューションで味付けされます。 概して、側への一歩は痛みで脅かされます。 リンターは含まれていません。 アップグレード時の同様の状況、APIは最小限であり、規則は簡単です。
• Electrodeは高度な設定ベースであり、ほとんどのスクリプトは最初から開いているため、最初はわずかなショックを引き起こしますが、理解するとすぐに人生はすぐに楽になります。 したがって、より複雑なケースでは、より適切に準備できます。 残念ながら、かなりの量の魔術がまだフードの下で発生しているため、決して簡単ではありません。 適切に調整されたESLintが含まれます。 ここでアップグレードすると、すべてが悪化します。 突き出ている内臓の数は非常に多いため、将来何かを壊す可能性も大きいです。
• カスタムでは、あなたは自分でいます。 あなたがするように、それはそうなります。 自分でベストプラクティスを探しているので、自分で解決策を選択しているので、プロジェクトの最初から最後の日までです。 アップグレードでは、すべてが一般的に非常に悪く、いつでも何かが壊れる可能性があります。

国際化

便宜上、ローカライズされた行は、順列と偏位を含む標準形式である必要があります。 翻訳会社が簡単に理解できるものが望ましいのは、ほとんどの場合、翻訳会社が混乱するからです。

提供されるフレームワークのいずれも、翻訳のための手段を提供しません。 ただし、簡単に追加できます。 検索後、集中型の非同期ブートローダーが最適に機能することがわかりました。この場合、各言語は個別のチャンクになります。 これは、言語をパラメーターとして受け取り、その言語の非同期に読み込まれた行を返す関数を作成することで実現できます。 const loadStrings(lang) => import('./strings/'+lang)



（この構造はすぐに動作する可能性は低いが、本質は明確である必要があり、その前にWebpackコンテキストを作成して1の束を保証することができる言語= 1チャンク。

ライブラリ： FormatJSおよびFormat Message （どちらもいわゆるICU Formatで動作します ）。

文字列をトークンで整理するのが最善です。つまり、 {TOKEN: {en: 'English', fr: 'French'}}



これは、開発者と翻訳者にとって簡単です。 「like token」が英語の文字列である逆のアプローチは、それ自体を正当化しませんでした。

比較

規律\名前	Reactアプリ	電極	Next.js	カスタム
動的ルート	はい	はい	DIY	はい
サーバーレンダリング	いや	はい	はい	DIY
SSR最適化	SSRなし	はい	いや	DIY
CSS	はい	はい	悪夢	DIY簡単
プリプロセッサ	悪夢	悪夢	悪夢	DIY簡単
重要なCSS	DIY	プラグイン	いや	DIY
コミュニティ	大きい	そこにある	そこにある	あなた自身で
テスト	冗談	幻	DIY	DIY
基本コード	ゼロ	たくさん	ゼロ	たくさんの
構成	ゼロ	たくさん	ゼロ	たくさんの
ドキュメント	いいね	まあまあ	在庫あり	散在する
簡単な学習	座って行った	許容できる	かんたん	悪夢
さらなるトレーニング	死にやすい	一生懸命	一生懸命	悪夢
サーバーエンジン	nginx	ノード	ノード	ノード
カスタマイズ	追い出して死ぬ	許容できる	悪夢	何でも
初期インストール	かんたん	口頭で	かんたん	悪夢
予測可能性	いいね	まあまあ	悪い	悪夢
アップグレード	ゴージャス	悪くない	まあまあ	悪夢

評決

サーバーサイドレンダリングを行わない場合（何も販売しておらず、アプリケーションはGoogleによってインデックス付けされておらず、一般にプライベートです）、 Create React Appに安全に目を向けることができます。これは最も人気がありシンプルです。 少しカスタマイズすることもできます。 ただイジェクトしないでください、それは価値がありません。

サーバーのレンダリングが必要であり、いくつかの制限がありますが、準備ができている場合は、 電極を選択します（条件として、多数のファイル、冗長性、構成に怖がってはいけません）。 パフォーマンスが心配な場合にも適しています。

さらに大きな制限に耐え 、ミニマリズムを愛する準備ができている場合は、 Next.jsをご覧ください。

そして最後に、常にカスタムがあります。 幸いなことに、 Webpack Blocks 、 React Serverの作成 、 React Router 、 Reduxなどのライブラリは非常に簡単です。 唯一の問題は、毎回同じコードを繰り返さずにアプリケーションを迅速に作成するための知識の交換とプロセスの開発です。