【環境構築】Next.js ×　TypeScript　~FW/ライブラリ解説~

一言：「Mac買いましょう」意識することが少なくて、動作が早いです。。。
　　　　※ローカルが遅いのは単純にスペックが足りない。。→CPUやメモリのせい

教訓：エラーは『読んでからググる』※すぐググらない
※なれるとエラーやドキュメントの英語ぱっと見ればわかるよ！

#【技術選定】
フロントエンド開発に役立つライブラリ
<b>どのFWでどう差別化できるのか、明確に選定基準をもつ</b>こと
##Vue/React/Angular
###①フレームレートの比較（滑らかに表示できるか？）
※単位：fps
>Angular(21.6)　＞　React(19.7)　＞　Vue(9.4)

###②メモリの使用量（実行の安定性）
※メモリ使用量：ＭＢ
>Vue(172)　＞　Angular(73)　＞　React(55)
※数値が小さいほど省メモリ

###③ライブラリの容量(素早く読み込めるか？)
※（総容量ＫＢ/総転送量ＫＢ※gzip通信）
>Angular(230/72.2)　＞　React(122/40.3)　＞　Vue(94.9/35.5)

>※Angularが他のライブラリより重たい。
ただし、gzip通信が効くと30~35KB程度しか容量の違いはないため、<b>よほど最適化したい場面を除いてライブラリの容量は気にしなくてＯＫ</b>


※zgip通信：
>メリット：ファイルサイズを小さく（通信料を削除）して、ページ表示高速化を図る

>デメリット：リクエスト受けるたび圧縮ファイルを作成するため、サーバーＣＰＵに負荷がかかる


###ライブラリの起動時間（素早く起動できるのか？）
※スクリプティング(ミリ秒)
>Angular(544)　　
React(197)　 
Vue(263)

※<b>Reactがライブラリの中では『最速』</b>。より早くウェブページを表示するFMPまで高速化する必要性がフロントエンド界隈で高まっている。

>※FMP（ファーストミーティングペイント）：
>ページ表示速度の指標としてユーザに必要なもの（UX）


####■まとめ
・Reactが総合的な性能面で有利
・Angularは起動に不利だが、実行性能（ﾌﾚｰﾑﾚｰﾄ）は良好
・Vueは大量にコンポーネントを配置する場合は不利


##Vue/React/Angularのプラス面/マイナス面

###◆Angular
【プラス面（＋）】
>・フルスタックなので、ライブラリを調べたり導入するコストが不要。（最初からすべて入っている）
・<b>大規模本格開発向き</b>（開発ルールがハッキリ）

【マイナス面（-）】
>・堅牢だが制限が多い
・多機能であり、小規模なアプリにはオーバースペック
・他２つに比べると、部分的な導入が難しく既存アプリなら全入れ替えが必要なイメージ
・<b>開発を一度Angularで始めると基本的に乗り換えはできないので引き返せない</b>


###◆React
【プラス面（＋）】
>・ライブラリ系が特に豊富
・スモールstart可能（導入コストはAngularより低い）
・<b>Vue.jsよりは大規模開発、複雑なアプリに向く</b>
・Simple。本体含めライブラリそれぞれは１つのことを実現し、複数組み合わせると要求が実現可能。

【マイナス面（-）】
>・JSX記法だとJSの中にHTMLを書くことになり、ほぼ慣れだが感覚的に嫌う人が多い。デザイナーとの分業で困ることも
・公式以外が提供しているライブラリの取捨選択に知識、調査が必要



###◆Vue
【プラス面（＋）】
>・スモールstart可能
・Reactと異なり、コンポーネント内記述は、基本HTMLとJSが独立。よりきれいに書ける
・<b>特にシンプルなアプリに向く</b>
・Easy。主要ライブラリは最適解があるので迷わず勧められる

【マイナス面（-）】
>・<b>大規模アプリやコンポーネントが入り込んだ構成になると、Angular、Reactが優勢</b>
・JSの中にHTMLを描かない
→しかし、高度な使い方で再利用可能なコンポーネントを使いだすと、JS中にHTMLを書くためReactと違わなくなる


#Next.js
※ここでライブラリとＦＷの違いをおさらい
>ライブラリ：必要な個所で呼び出す
FW(ﾌﾚｰﾑﾜｰｸ)：全体の処理が用意されており、一部を自分で書いてはめ込む

##Next.jsとは？？
>Reactを用いることを前提としたフレームワークで、
モダンかつ強力なフロントエンドフレームワーク。
CSSやSaasもサポートされているので非常に便利。

※Saasについて

https://digitalidentity.co.jp/blog/creative/css-sass.html

##Next.jsの強み4選
###①SSR / SSG
>React：シングルページアプリケーション(SPA)として単体の巨大なJavaScriptを生成
Next.js：アプリケーションを事前にページ単位でレンダリング

![https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_9504_15f5f7fe-a858-d7aa-0a83-adbc9eba61db.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/684145/08e78a23-9a00-db60-51bd-520d5469169c.png)

![https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_9504_6d312b92-92a8-39bb-dc22-4c4eed9a19d8.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/684145/36b11703-c5f2-920f-139b-bb02d9c6f331.png)

レンダリングにも2種類方法がある
>・SSR(サーバーサイドレンダリング)：クライアントからのリクエスト時
![https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_9504_6226300e-8133-40c0-831c-f58b3a2b2c0d.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/684145/2737cea6-9bd6-9cbf-121a-b9ada8239928.png)

>・SSG（スタティックサイトジェネレーション）：ビルド時
![https___qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_9504_267529c9-b5dc-f21e-4a24-d6b37cad3078.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/684145/fa1ed317-5c8b-8c7a-7555-1b65a0fd1516.png)

※各ページの読み込み時のDLファイルサイズを削減かつ、SEOに有利

※クローラー：JavaScriptを上手く動かしてくれないため、白紙のページに見えてしまいSEOに悪い。（Reactの場合）









>今は、実用上リクエスト時までページの静的な内容が確定しないのはレアケース。リクエストごとにHTMLを生成するより、<b>ビルド時に１度生成したほうがパフォーマンスは高いし、SSGが主流</b>。

※SSR
SSRのデメリット：
>1.SSR用のサーバーを持たないとダメ
2.サーバーサイドのセキュリティの危険性
3.パフォーマンスもSEOもSSGの方が優秀！

><b>認証ページはSSGできないが、そもそも秘匿情報が含まれているためSEOさせる必要がない</b>。<b>個人情報のキャッシュミスも防げる</b>。

###②ファイルベースルーティング
>React：SPAとしての性質上、疑似的にURLを書き換えて見かけ上のページ遷移をしてる。URL
URLとコンポーネントの対応付けが面倒。★<b>表示はJSで書き換えられてる</b>★

>Next.js：pages/ディレクトリに置いたフォルダ/ファイルの構成に従ってHTMLを生成して、ページ遷移する。<b>ルーティングライブラリは不要で、URLの構造に合わせてjs(ts)ファイルを置くだけ（ラク）</b>

###③開発サーバの部分的な高速リロード
>React(Webpak)：開発サーバは変更を検知して『ページ全体』をリロード
Next.js：ソースコードの変更を検知して、<b>stateを保持したまま、変更箇所のみ</b>更新

###④画像最適化(Next.js　10.0.0以降~)
専用の画像コンポーネントが追加され、配置されるサイズに応じて元画像をトリミングして配信。
>→必要サイズデータだけDLするので、<b>画像表示を大幅に高速化</b>



#あとはLet‘ｓ構築

https://nextjs.org/docs