フロントエンド

状態管理#

例えば、次のようなウェブページを想定します。

画面にボタンAとボタンBがある。
ボタンAを三回クリックした直後にボタンBを二回（計5回）クリックすると画面が爆発する。
上記パターンから外れた段階で状態はリセットされる。

上記のようなページを作るためには、まず以下のような実装を施す必要があります。

let countButtonAClicked = 0;
let countButtonBClicked = 0;

when (ButtonA clicked){
    countButtonAClicked++;
}

when (ButtonB clicked){
    if(countButtonAClicked !== 3){
        // リセット
        countButtonAClicked = 0;
        countButtonBClicked = 0;
    }else{
        if(countButtonBClicked !== 1){
            countButtonBClicked++;
        }else{
            // 爆発
            explode()
        }
    }
}

上記は疑似コード（もどき）ですが、見てわかるのがcountButtonAClicked、countButtonBClickedをウェブページの状態としてメモリ空間上に保持する必要があるということです。
これらの状態をもとに次に行う処理を分岐しています。

上の例は高々二つのブロックスコープ内だけで参照されていますが、これがもっと多くのコンポーネント（ここではウェブページのボタンやインプットフィールドのことだと思ってください。）で参照や更新する必要があった場合はどうでしょうか。
コンポーネントが多くなっていくごとに、変数の参照や更新がいたるところでしっちゃかめっちゃに行われ、収集がつかなくなるのが目に見えます。
そこでウェブページの状態をフレームワークで管理し、参照や更新のインターフェースを共通化させる、という考えが生まれます。（React.jsではstate、Vue.jsではdataなどの概念が提供されています。）

この実現をサポートするために登場したものが、例えばReduxやVuexといった状態管理フレームワークです。
Facebookによって、データの更新から参照までのフローを一方通行的にするFluxアーキテクチャというものが提案されました。(ちなみにReact.jsの開発元はFacebookです。)

シングルページアプリケーション(SPA)#

現在のモダンなウェブアプリケーションにおいて欠かすことのできないコンセプトが、シングルページアプリケーション(SPA)です。
コンテンツをページごとに用意するのではなく、HTMLで表示する部分はあらかじめ構築しておいて、コンテンツごとに必要なデータを適宜サーバーから受け取り、JavaScriptにデータの描写を行わせるアプリケーションです。
いちいちページ全体をサーバーに問い合わせることを避け、トラフィックの減少やパフォーマンスの向上を狙ったアプリケーションです。