前回の見取り図記事でスコープ外にした用語について、です。

書かなくてもいいかとも思ったんですが、思ったより前回記事が読まれたので、補足的に書こうと思います。
具体的に何を扱うかは、目次を見てください。

ビルドとデプロイ

ビルドとデプロイの違いはなんでしょう？
開発環境によって微妙に差異があって、業界標準でこう、と決まってるわけではないんでしょうけど、一般的には下記を指すと僕は認識しています。

ビルド: ソースコードのコンパイル、関連ファイルの紐付けを行い、実行可能な状態にする
デプロイ: ビルドして、ユーザーから実行可能な状態にする

デプロイは自分以外のユーザーが実行できる環境でのビルド、と言ってもいいかもですね。

デプロイ環境（Vercel, Netlify, Heroku）

で、Webサイトのデプロイ環境について。
かつては自分でサーバーサイドのミドルウェアをセットアップする必要がありました。
所謂LAMP環境（Linux/Apache/MySQL/PHP or Perl or Python）という構成ですね。

ただ今はNext.jsみたいなフレームワークを使うと、Node.jsでいい感じにしてくれるので、あまり自分でミドルウェアをいじることはないかなと思います。
また、それを前提にしたサービスもありまして、イマドキはそっちを使うのが圧倒的に楽だと思います。

デプロイ環境としての選択肢は、列挙すると下記のような候補があります。

Firebase Hosting, Github Pages, Heroku, Netlify, Vercel, さくらのVPS, AWS,
GCP

これでもあくまで一部です。

色んな観点はあるかと思いますが、Webサイトのデプロイとなると、Heroku, Netlify, Vercelが候補になるかなと思います。

Heroku: ヘーロク
Netlify: ネットリファイ
Vercel: ヴァーセル

という読み方でいいと思っています。
（もし違ったらコメントで指摘してください）

サービス開始が古い順で、Heroku, Netlify, Vercelです。
僕はHeroku, Vercelは利用しており、Netlifyは未経験です。
基本的にはGithubのリポジトリを連携してあげると、デプロイ作業をやってくれて、アクセス可能なURLを生成してくれます。

もしつくってるアプリがNext.js製なら、Vercelを使うといいと思います。
なぜならNext.jsを開発しているのがVercel（旧ZEIT）という会社だからです。

Vercelだと、Githubのプルリク出した時点でデプロイが走って、
本番環境とは別の場所でURLを生成してくれて、実際に動いているWebサイトとしてレビューができます。

たぶん企業戦略的には、個人ではほぼ無料・無制限で使わせて、自分たちのサービスの良さを認識してもらって、
ビジネスユースにするタイミングで有料プランにして儲けを出す、ということなんだと思います。

Webアプリケーション設計

SPAとかSSRとかSSGとか、その辺のアルファベット3文字熟語が入門した当初めちゃくちゃ混乱しました。
その辺について書いていきます。

SPA: Single-Page Application

より正確な定義は↑をご覧ください。

SPA登場以前のWebサイトは、HTMLページがあって、CSSのスタイルを適用して、JSでちょっとしたスクリプトがある、という構成でした。
データの更新をかける場合、多くはページ遷移、つまりURLの変更が必要でした。

具体的には地図のWebサイトを考えるとイメージしやすいと思います。
紙の地図をそのままスキャンして、東京都の地図、埼玉県の地図…… みたいにページをつくる感じです。
東京都の地図のページで、上にあるボタンを押すと埼玉県の地図に移動、みたいにしていました。
かつてはそれでも紙で見てたものがインターネット経由で見れるというだけで、ちょっとした感動がありましたが、操作性はお察しでした。

SPAを採用して操作性に革命を起こしたのが、ご存知Google Mapです。
Google Mapはユーザーアクションに対して、ページ遷移ではなく、データの更新のみで対応しました。
それによってユーザー体験が飛躍的に向上しました。

この説明記事を書くために、SPAじゃない地図サイトを探してみたんですが、官公庁のちょっと古めのサイトでも最近はもうSPAでした。

SPAのフレームワークで最も有名なのがReactです。

SPAの弱点

そんなSPAにも弱点はあります。
それはSEOに弱いことです。
（SEO: Search Engine Optimization。要はGoogleの検索順位でより上位に出るように頑張ること）

なぜかというと、SPAのページは、Googleのクローラーがちゃんとページ情報を読めないからです。

画像出典

SPAのページ、たとえばReactは最初に空のHTMLページを返します。
そこからJavaScriptの処理でHTML要素を生成して、ページをつくっていきます。
なので、Googleのクローラーは空のページとして誤認識してしまい、正しくページを評価してくれません。

そこでモダンなフレームワーク、と言っても僕はNext.jsしか使ったことがないので、
Next.js前提で書かせていただきますが、Pre-renderingというアプローチをします。

画像出典

空のページを返すのではなく、データありの状態で返します。
（このデータあり状態、個人的には完全にレンダリング処理が終わった状態で返してる認識でしたが、
よく読むとLink要素などは遅延すると書いてあって、何が即時返って、何が遅延するのかもう少し詳しく知りたいですね）

SSR: Server-side Rendering

Pre-renderingの方針として二つあります。
それがSSRとSSGです。
まずはSSRについて説明します。

画像出典

SSRは、ユーザーがブラウザからアクセスしたタイミングで、レンダリングを行って、データを返します。
Next.jsだと、getServerSideProps()というメソッドを使います。

function Page({ data }) {
  // Render data...
}

// This gets called on every request
export async function getServerSideProps() {
  // Fetch data from external API
  const res = await fetch(`https://.../data`)
  const data = await res.json()

  // Pass data to the page via props
  return { props: { data } }
}

export default Page

これでGoogleのクローラーもあなたのサイトを適切に評価できます！
よかったですね。

SSG: Static Site Generator

SSG、”Generator"なんですね。
ずっと"Generation"だと思ってました。
（つまりSSGは「静的サイト生成してくれるやつ」であって、「静的サイト生成」ではない）

SSRにも弱点はあって、ユーザーがアクセスしたタイミングでレンダリングが走るので、その分表示が遅くなります。
データのリアルタイム性がさほど要求されない内容で、SSRを採用してしまうと、筋が悪いような感じがします。

たとえば個人ブログなんかは、更新頻度なんてそんなにないでしょうから、
ユーザーのアクセスタイミングでHTML要素を生成するのではなく、あらかじめ生成したものを置いておきたいですよね？

それが、SSGで実現できます。

画像出典

デプロイの際に、HTML要素を生成して、ユーザーがアクセスするときはその静的ファイルを表示します。
Next.jsではgetStaticProps()を使います。

export async function getStaticProps(context) {
  return {
    props: {}, // will be passed to the page component as props
  }
}

SSRとSSG、それぞれ使いどころがあるので、データの性質に応じて使いわけるのが吉です。

React, Next.js以外のフレームワークと用語

前回のWebフロントの見取り図では、React → Next.js という主流のフレームワーク以外は割愛しました。
選択肢としては他にも色々あるので、そこを書いていきたいです。

React Native

モバイルアプリ（iOS/Android）をReactで開発できるフレームワークです。
クロスプラットフォーム開発、と呼ばれる種類です。

Webフロントエンジニアがいっぱいいる環境で、ちょっとしたモバイルアプリつくる必要が出てきたときに有用です。
が、モバイルエンジニアの雰囲気的にはFlutterの方が人気に見えます。
Flutterはプログラミング言語がDartというちょっと珍しい言語になります。

Dart自体はモダンなプログラミング言語の要素を最低限おさえているという感じのつくりになっていて、
実際Flutter開発をやってみると、開発者体験は非常によかったです。
当初はAltJSとしてDartは開発されたそうですが、今だとFlutter専用言語みたいになってますね。
（Googleの社内でFlutterチームの近くにDartチームの島があったそうです）

僕がクロスプラットフォーム開発をやるのであれば、現状ならFlutterを選択しますかね。

Redux

2015年にリリースされたOSSです。

https://github.com/reduxjs/redux

かつてはReactとセットで導入する雰囲気でしたが、いつの間にかReactだけになりましたね。

というのも、Reduxというのはあくまである設計を実現するためのツールに過ぎません。
Reactの流行ほどはReduxは大衆に受け入れられなかった、と言えるのではないでしょうか。
ただじゃあReduxは過去のものか、というとそういうことではなく、大規模アプリケーションをつくる際には選択肢になるのではないでしょうか。

Reduxをちゃんと説明すると、「Fluxのアーキテクチャーを、副作用のない純粋関数によって実現するアーキテクチャーであり、ライブラリ」ということになります。
（副作用: ここでは関数の入力、出力以外で状態変更を伴う処理のこと）
ちゃんと説明するともうそれだけで一記事なので、ここでは過去にFlux使ってみた記事を貼っておきますので、興味があったらたどってみてください。

データフローを一方向にすることを設計として強制することで、
どんなに機能追加してもカオスにならないようにする、というのがFluxの思想です。

Reduxはそれを、Elmに影響された、副作用のない形で実現したので、脚光を浴びました。
（Elm: 関数型言語）
更には、JavaScriptによる実装は318行というコード量だったため、軽量な記述でFluxの思想を実現している点でも注目されました。

僕自身がWebフロントエンドにキャッチアップしたのが2021年のことだったので、
素朴に「ReactとReduxってセットじゃなかったんだ……」と思いました。
2016年ぐらいのQiitaだと、なんとなくセットで議論されてた印象があります。

React自体は、Viewの実現方法については規定していますが、データ（Model）をどう扱うかは自由なので、
Reduxを入れるもよし、入れずにやるもよし、というのが最近のトレンドみたいです。
「状態管理フレームワーク」という名前で、Redux以外のフレームワークは色々登場しています。

これは僕個人の意見ですが、Fluxの仕組みは確かにスケーラビリティーを考えるなら理論的には上手く行くと思うんですが、あんまり感覚的に気持ち良くない感じがします。
なのでちょっと反論もしづらくて、職場のチームリーダーがFlux推進派だったらそれに従うとは思いますが、
自分で好き勝手できるプロジェクトだったらたぶん採用しない、みたいな感じです。

hooks

Reduxがセットにならなくなった一因として、hooksが便利だったというのがあります。

↑正確な定義は公式を見てください。

通常のReactコンポーネントは状態を保てません。
とはいえ、それだと破綻する場合が稀によく出てくるので、hooksという仕組みができました。
わかりやすい解説はたぶん↓のQiitaを見るといいかと思います。

useXXXという名前で、副作業のある処理を記述できます。

Vue.js

Vue.jsは2014年に公開されたJSのフレームワークです。
開発したのはEvan Youで、（元？）Googleの中国人エンジニアの方っぽいですね。

https://evanyou.me/

僕が観測する範囲の印象ですが、Reactよりは人気ないものの、そのわかりやすさから一定数の利用者がいる、みたいに見えています。
（僕自身は使ったことないんで、深い話はできません）
公式のコードサンプルを見ると、↓の感じらしいです。

<div id="app">
  {{ message }}
</div>

var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!'
  }
})

Reactの仮想DOMだったり、宣言的UIだったりはかなり初学者の心を折るに足るものだとは思うので、Vue.jsの構文の方がハードルは低いかと思います。

HTMLの構文に沿いつつ、ロジック部分はJSで直感的に記述できるというのがポイントかと思います。
ReactはHTMLは最低限にして、JSで全てやるみたいなところがあるので、だいぶ個性を感じますよね。

Nuxt.js

そんなVue.jsの開発フレームワークがNuxt.jsです。
Next.js → Nuxt.jsという流れみたいです。

Next.jsもNuxt.jsも、言うたらあるフレームワークの元のベストプラクティス集的なフレームワークで、
開発フレームワークの二段重ね、いやそれどころかNode.jsも乗ってるんで、OSSの三段重ねみたいになってますので、
もはやフレームワークという言葉は次世代に突入してるんだと思います。

Next.jsはReactを使ってシュッとやるフレームワークなんですが、Nuxt.jsはVue.jsをシュッとやるフレームワークです。

index.vue

<template>
  <h1>Hello world!</h1>
</template>

みたいにして、DOM要素っぽく記述するスタイルのようです。

Angular

僕が今参照している古い本（といっても2018年出版なんですが……😅）によると、

当時のGithubのOSSのスター数は、React > Vue.js > Angular だったそうです。

https://github.com/angular/angular

今でもそんな変わんないんじゃないかなと思って計測してみました。
2021/10/25時点です。
()内は2018/03/14。

React: ⭐️177,000(←90,504)
Vue.js: ⭐️190,000(←86,633)
Angular: ⭐️77,200(←33,994)

Next.js: ⭐️74,900
Nuxt.js: ⭐️38,400

これだけ見ると、React/Vue.jsの二強ですね。
スター数だけだとVue.jsの方が多いですけど、とっつきやすさの差ということで、納得感はあります。

で、Angularの話ですね。
Googleを中心にして、2012年に「AngularJS」としてリリースされました。
2016年にバージョン2として「Angular」という名前になりました。
経緯としては、2012年に発表したフレームワークが時代に合わなくなったので、根本的に書き換えて、ほぼ別のフレームワークになった、という感じみたいです。

2010年代のGoogleといったらもう神みたいなもんでしたけど、
その一方で流行らなかったものはそれなりに生み出していて、Angularもその一つと言っていかもですね。
（後はGoogle+とか）

完全エアプで申し訳ないんですが、Hello Worldのコードは↓らしいです。
（エアプ: ゲーム用語で、プレイしたことがないのにプレイしたかのように語ること。エアプレイ）

import { Component } from '@angular/core';

@Component({
  selector: 'hello-world',
  template: `
    <h2>Hello World</h2>
    <p>This is my first component!</p>
  `
})
export class HelloWorldComponent {
  // The code in this class drives the component's behavior.
}

<hello-world></hello-world>

出典

TypeScriptが標準なのと、Viewだけでなく、データ周りの管理方法があって、更にCLIもあって、
大規模サービス向けのフルスタックなフレームワークというのが一応の売りのようです。

Tailwind CSS

ここまでJSのフレームワークを紹介してきました。
ここではCSSのフレームワークを一つ紹介させてください。
それが、Tailwind CSSです。

個人的な感想ですが、JSの2010年代の進化もすごいですが、CSSもだいぶ進化していると感じました。
HTMLはすこし進化している、という感じです。
JSでやろうとすると難しいけど、CSSだと実は簡単に実現できるよ、みたいなことが結構あります。

具体的に書くと、カード風のデザイン。
これをJSで実現しようとすると、それなりに大変で、僕はてっきり世の中の多くのサイトがカード風のデザインを実現しているのを、
JSの何かでやっていると思っていましたが、CSSのFlexboxを使って実現しているというのを知りました。
Flexboxなんかはもう僕のイメージしているCSSの枠を超えていると思うのですが、まあなんかすごいですね。

で、そんなCSSを更にパワーアップさせるTailwind CSSです。
どのぐらいパワフルなのか直感的に知るためには、公式サイトのトップページを見るのが一番いいと思います。

https://tailwindcss.com/

Tailwind CSSのわずかな一指定で、見え方がどれだけ変わるかを示しています。

↓雰囲気はこんな感じです。

<figure class="md:flex bg-gray-100 rounded-xl p-8 md:p-0">
  <img class="w-32 h-32 md:w-48 md:h-auto md:rounded-none rounded-full mx-auto" src="/sarah-dayan.jpg" alt="" width="384" height="512">
  // ……
  </div>
</figure>

CSSでプログラミングみたいな感じで要素のデザインを指定できる、というのが嬉しさです。
ただ人によって合う合わないがあり、そもそもデザイナーだとこの雰囲気はちょっと苦手な気もしますので、賛否両論はあるみたいです。
僕自身はすごいなあと思いつつ、ちょっととっつきづらかったので、導入は見送りました。
今後CSSをハックしたい、となったら導入を検討するかもです。

Obsoleteなトピック

ここまで書いた内容は、トレンドのトップというわけではなかったとしても、2021年現在も十分使う人がいるよね、というものでしたが、
ここからはWebフロントエンドの中でObsolete（時代遅れ）扱いになっているトピックを扱いたいと思います。

新規で使うことはないトピックなら知らなくていいんじゃね？　という考えもあるかとは思いますが、
たぶん名前ぐらいは知っといた方が、色々話が早いんじゃないかなと思います。
また、調べてみたら開発が完全停止になってるわけではないフレームワークでした。
既存ソースコードの保守で触れる方もいるのかと思うので、表現には気をつけたいと思います。

jQuery

2006年にリリースされたJavaScriptライブラリです。

https://jquery.com/

<script
  src="https://code.jquery.com/jquery-3.6.0.min.js"
  integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4="
  crossorigin="anonymous"></script>

（Wikipediaから引用）

↑こんな感じでライブラリを指定して、

$( "button.continue" ).html( "Next Step..." )

こんな感じで、DOM要素を直指定して操作できます。
現代のモダンJSフレームワークと比べると、ハードルがだいぶ低いかなと思います。
ライブラリのサイズも軽量で、「write less, do more」がキャッチコピーです。

弱点は保守性・可読性がめちゃくちゃ低くなることです。
サンプルコードくらいの規模ならいいですが、会社のプロダクトレベルの規模だと、書いた本人でも何がどう動くのか容易にわからなくなります。

Web企業は転職が多いので、担当者が実装時の記憶を掘り起こして保守していた状況で、その担当者が辞めて、何も知らない後任が引き継いで……みたいな状況は結構あったと思われます。
たぶんネット上でjQueryをめちゃくちゃDisってる人は、そういうコードを保守させられたトラウマがあるのでしょう。

https://github.com/jquery/jquery

で、僕の中では完全にjQueryって過去のものだったんですが、2021/03/04に3.6.0がリリースされてますね……
何も言いませんが、ビックリしました。

CoffeeScript

2009年からOSSとして開発されているAltJSです。

2010年代前半には価値があったし、人気もあったAltJSみたいなんですが、
2015年にECMAScript 2015が登場して、CoffeeScriptの「先進的な記述」が吸収されて、存在価値が薄れてしまいました。

Grunt/Gulp

タスクランナーです。

かつて（2016年頃）はなんかBabel/Gulp/webpackがフロントエンド開発でまず入れる意味わからん三兄弟という感じでしたが、いつの間にかGulpくんはいなくなっていました……
当時の僕はWebフロントエンドに入門したいなあと思いながら、Qiitaのトレンド記事を眺めてはなかなか何したらいいのかよくわからない日々を送っていました。

Grunt/Gulpはタスクランナーです。
要するに、ビルドのときに色々コマンドを実行してくれるやつ、という認識でいいみたいです。
シェルスクリプトやmakeと同じです。

2016年頃のWebフロントは、自分のWebアプリをビルドするために、こだわりの設定をGrunt/Gulpに行って、毎回走らせていました。
当時はGruntの人気が失速して、Gulpが主流だったみたいですが、今となってはGulpすら要らなくなりましたね。

個人的には大きなWebフロントエンドへの参入障壁だったので、この作業がなくなったのはすごく助かりました。

Ajax

ネイティブな発音だとエイジャックスらしいですが、アジャックスでも通じるとは思います。
Asynchronous JavaScript And XMLの略です。
別にObsolete、というわけではないんですが、用語自体は今あんま使わないと思うので、この枠に入れさせて頂きました。

2005年につくられた言葉で、Webアプリケーションのページ全体を更新するのではなく、必要なデータのみを非同期更新するアプローチです。
よく例として出されるのがGoogle Mapですね。

別に特定の技術、というわけではなくて、一つの手法の名前であって、名前にXMLと入ってますが、別にXMLであることは本質ではないそうなので、
2021年現代のWebフレームワークの非同期処理も、Ajaxと言えばAjaxでしょう。

ただ、この用語自体はちょっと古いWebの雰囲気を持っているので、注意した方がいいと思っています。
たとえば古本屋で買った技術書の中で、
「最新のWeb技術では、Google MapのようにAjaxという技術を利用して……」
みたいな文言が出てきたら、その本の出版年を確認した方がいいです。

まとめ

長くなりました……
本来何個かに分割した方が良かったんでしょうが、勢いで一記事として書きました。
書いておきたかった内容は全部盛りこめたので、適宜興味のないトピックは飛ばすような感じで読んでいただけたらと思います。

この記事書きながら、改めて2016年ぐらいのWebフロントは混沌としてたんだなと思いました。
前回の見取り図記事だと、そこを入れると入門記事としてよくないなと思ったので、スコープ外にしたんですが、正解でした。

この記事が何かのお役に立てば幸いです。

Discussion