なるせみさんのyoutubeの内容の前半の総論部分をまとめました！

フロントエンドとバックエンドの情報のやり取りの種類は大きく分けると２つ

①フロントからのアクセスに対して、HTML、CSSをバックエンドで生成してフロントに渡す
②フロントからのアクセスに対して、データのみをフロントに渡し、フロントでHTMLファイルを生成する
　データ：　{name: shun}

②についての技術の歴史

javascript
↓
jQuery
↓
jsフレームワーク(angular, react, vue)

各技術の比較

javascript

<buttom id='excute'>run</button>
<p id='message'><p>

const excuteButton = document.getElementById('excute');
excuteButton.addEventListener('click', function() {
    const messageParagraph = document.getEllementById('message');
    messageParagraph.textContent = 'excute button clicked';
});

長い、、、

jQuery

<buttom id='excute'>run</button>
<p id='message'><p>

$('#excute').click(function() {
    $('#message').text('excute button clicked');
});

vue.js

<p>Message: {{message}}</p>
<button @click='executeButtonClick'>run</button>

methods: {
    executeButtonClick() {
        this.message = 'excute button clicked';
    }
}

比較

javascript長い、辛い、、を解決したのがjQuery
jQueryでチーム開発は辛い、、自由すぎ、、を解決したのが、jsフレームワーク

チーム開発辛い、、について

$('＃')に書いた要素ならなんでも自由に触れる。
処理を書く人の責任が重い。
遠く離れた要素を触ることにより、可読性や保守性低下。
触ると危ない要素を触ってしまうリスク。
↓
全員に「自制力」が必要になる。
ある程度制限がないと、チーム開発が難しい。。

ライブラリかフレームワークか

jQueryはライブラリ。
ライブラリは、自由にどこからでも実行できるイベントの集まり。
その関数をどこでどう使うかは、プログラマーが決める。

フレームワークは、実行できるイベントをフレームワークで管理している。
あくまでイベントを呼び出すのはフレームワーク。
そのイベントに紐づく処理を関数として定義するだけ。
フレームワークで許可していない動きは実現することはできない。

ハリウッドの法則　「私を呼び出すな、必要ならば私から呼び出す」

この制限のおかげでチーム開発にある程度の規律が生まれる！

宣言的UI

jsフレームワークは、宣言的UI
関数を予め宣言するだけ。「メッセージに文字列をセットする」

jQueryは逐次実行する。
「ボタンをクリックして、メッセージに文字列をセットする」までを一連の流れとして記載している

jsフレームワークは、テストが簡単。メソッドが細かい単位で定義されているのでそれまでの過程を気にせず単体テストが可能。
DOMが想像しやすい（何のための処理なのか読みやすい。jqueryはどこで何を呼び出して何をしているのか、js見ないとわからない）

SPAについて

SPAは
最初のリクエストで全ページのHTMLファイルをjavascriptで読み込む

「ページ繊維」と「データリクエスト」が分割できる
「ページ繊維」のためにサーバーへのリクエストが不要

その代わり初回読み込みが遅い

フロントエンドの難しさ

非同期なのでいつでも入力を受け付けており
制御しないといけないことがたくさんある

より滑らかに、よりリッチになってきていてさらにこの流れは加速する

dog　year
せっかく作ったものがおじゃんになりやすい
作ってみないとイメージがつかないので
運用する中で仕様変更が起こりやすい

柔軟な設計が必要

やっぱり変える！ってなった場合に柔軟に対応できないとキリがない
ユーザーファーストでどんどんいいものを作るべきなので
仕様変更は致し方がない。

webは遅れている
コンポーネント思考自体は昔からあった
ソフトウェアではオブジェアクトを実装する

が広まっていない
修正が早い
コンポーネント思考は枯れたアプリ
HTMLが優秀すぎたのでコンポーネント思考が取り入れられるのが遅かった
めちゃくちゃリッチになるまである程度HTMLだけで対応できた

バックエンドはイベントドリブン、コールバックドリブン

コンポーネント思考はデザイナーに伝わりにくい

デザインシステムでイメージを共有する
アトミックデザイン

最終的にプログラマが作らないといけないから

GUIのアーキテクチャ

※サーバーは関係ない

MVC
MVP
MVVM

MVC

テレビゲーム
ユーザーが操作する controler
ユーザーに表示する view
処理する　　　　　model

controler → model → view 　→ controler

MVP

スマホ pcソフトウェア（パワポとか）

ユーザーが操作する view
ユーザーに表示する view
処理する　　　　　model
viewとmodelの橋渡し　presenter

view　→　presenter　→ model → view
view　→　presenter　→ model → presenter　→　view　（viewの役割が少ない）

MVVP

view　→　viewModel　→ model → viewModel → view
双方向バインディング
vueやangular

MVW

MVC MVP MVVPいろいろあってめんどくさい
結局何が重要かというと、
MとVを分割し、viewにビジネスロジックを書かないこと！

MとVとそれ以外のW(What ever)
Googleが提唱