HTML / CSS

2021.12.27 作成 | 2022.06.05 更新

【2021年12月更新】昨今のフロントエンド開発事情をまとめました

2021年時点の「フロントエンド開発」の手法やトレンドなどをまとめました。

今回紹介する内容は、ゴリゴリのフロントエンド開発（VueやReactなど）よりは、もう少し敷居の低い、一般的にコーディングと呼ばれる部分がメインになります。

細かいフロントエンド開発の技術を学ぶというより、「こんな開発方法や技術があるんだ」となんとなく昨今のフロントエンド開発の知識を得ることがこの記事の目的です。

フロントエンドのベースはあくまで HTML＋CSS＋JavaScript
モジュールバンドラーでJavaScript開発の効率がUP
HTMLやCSSにもモジュールバンドラーは使える
jQueryは時代遅れ？
- 0から勉強をするならjQuery？生のJavaScript？
Googleが新たに発表した「コアウェブバイタル」
- コアウェブバイタル計測方法
昨今のSEO評価の基準
CSS設計
<img>タグの新たな書き方
Sassの LibSass（NodeSass）は非推奨になった
最近聞くようになったCSSライブラリ達
JSライブラリ
- Nuxt.js、Next.js
TypeScript
SPA、SSR、SSG
ノーコードでの開発
フロントエンド開発とサーバーサイド開発の分離
サーバーサイドエンジニアが知っておきたいフロントエンドのこと
まとめ

フロントエンドのベースはあくまで HTML＋CSS＋JavaScript

VueやReactなど昨今様々な技術が存在しますが、PCの画面に表示されているWebサイトはあくまで「HTML＋CSS＋JavaScript」です。

HTMLで骨組みを作り、CSSで見た目を整え、JavaScriptで機能や処理を作る。どんなに難しい技術を使っていても、Webサイトはこの3つが基礎であり絶対に変わりません。

そして、昨今の「フロントエンド開発」を理解するのに欠かせないのが、「モジュールバンドラー」を用いた開発です。

モジュールバンドラーでJavaScript開発の効率がUP

「モジュールバンドラ」とは、複数のモジュール（ファイル）をまとめるツールです。

モジュールバンドラの代表はWebpackです。

例えば、3個の機能の処理が書かれたJSファイルがあるとします。これまでは1つのJSファイルに全ての処理を書いていました。これだと、開発時や修正時に触りたいコードを見つけるのが大変だったり、予期せぬミス（Aの機能を修正したつもりがBの機能も変わってしまった...みたいな）が起きる可能性が高かったです。

しかし、モジュールバンドラーの登場により、ファイルを分割して開発できるようになり、触りたいコードは簡単に見つけられ、修正した時の影響範囲も以前より小さくなりました。

以下のようなイメージです。

Webpackができること

モジュールバンドラーの代表であるWebpackには、様々な機能やプラグインがあり、それらを利用するとファイルをまとめる他にも様々なことができます。

Babelを用いてJavaScriptをひとつのファイルにまとめる（トランスパイル）
構文エラーのチェック
SassのコンパイルやAutoprefixerなどの実行
画像の圧縮

Webpackを使うには...

Webpackを使うにはNode.jsが必要です。

開発手順としては以下の通りです。

Node.jsをPCにインストール
Webpackの設定&必要な機能をインストール
開発時にWebpackを起動

モジュールバンドラーを使ったJavaScript開発の注意点

複数のファイルに分けて開発を行う場合、importやexportという構文を使いますが、これらはIEなどの古いブラウザには対応していません。そして、これらの構文はES2015（ES6）記法と呼ばれています。

import Class from './module/class';
export default () => { ... };

ES2015で書かれたJSを、古いブラウザにも対応したJSにトランスパイル（変換）するには、Babelを用います。

つまり、ES2015で書いたJSをWebpack&Babelでトランスパイルして、ひとつのJSファイルを生成する。そのファイルをサイトに読み込ませるのがモジュールバンドラーを使った開発の流れになります。

ES2015（ES6）とは

ECMAScriptというJavaScriptの標準化団体が2015年に発表したのがECMAScript 2015（ES2015）です。これには、JavaScriptの新しい書き方が多数含まれています。今では馴染みのあるconstやletなどの書き方もES2015から追加されました。

ちなみに、ES2015とES6はほぼ同義であり、人によって呼び方が違う程度の差です。一応公式はES2015と呼んでいるみたいですが、エンジニア界隈ではES6と呼ばれるほうが多いみたいです。

ES6の書き方を学びたい方は以下記事が参考になります。

参考：ES2015(ES6) 入門

HTMLやCSSにもモジュールバンドラーは使える

先程、JSファイルを分割して開発できると解説しましたが、HTMLやCSSもファイルを分割して開発できます。

HTMLはPugやEJS、CSSはSassやScssがそれに該当します。

PugやEJSでは、ヘッダーなどの共通パーツをファイルで分けられる他、変数やif文、for文などのロジックも使えます。超ざっくり言うと、WordPressのようなイメージです。

これらのファイルの拡張子は.pug、.ejsになります。

▼Pugの書き方の例

include header.pug

main.wrapper
  h1.title ページタイトル
  p.description texttexttext
  a(href="/")
    
include footer.pug

SassやScssは、CSS設計を学ぶなら是非覚えておきたい技術です。これらを使うことで、CSS設計のBEMやFLOCSSなどを最大限に活かせます。この時のファイルの拡張子は.sass、.scssになります。

コンポーネント（パーツ）ごとに、ファイルを分けるのが一般的な使い方です。

▼Sassの書き方の例

@use "object/header"

.hoge
  color: #f00
  font-size: 20px

著者のフロントエンド開発環境

私が普段、フロントエンドの開発を行う時は、Sass + ES6（JavaScript） + Webpack を使っています。これをベースに、案件によってPugやWordPress、JSフレームワークを使ったりしています。

jQueryは時代遅れ？

最近よく「jQueryは時代遅れだから勉強しなくていい・使わないほうがいい」のようなことを耳にします。

私の意見としては、「できれば使わない方向性のほうがいい」程度のレベル感で、完全に否定はしません。

jQueryにはメリットもデメリットもたくさんあります。まずはメリットから紹介します。

学習コストが低い（生のJSは書けないけどjQueryなら書ける...のような人はたくさんいます）
プラグインや技術記事が豊富
既存のサイトで使われている可能性が高い（私の体感だと5割ほどはjQueryが使われている）から、jQueryを勉強していればサクッと改修できる

▼jQueryと生のJavaScriptを比較したコード

// 要素取得
const $fuga = $('#fuga'); // jQuery
const fuga = document.querySelector('#fuga'); // JavaScript

// クラス追加
const $fuga = $('#fuga').addClass('piyo'); // jQuery
const fuga = document.querySelector('#fuga').classList.add('piyo'); // JavaScript

// フェードイン
$('#fuga').fadeIn(); // jQuery
// JavaScriptでは超大変
// 要素取得→sytle.displayの状態取得して状況に応じて条件分岐
// インラインスタイルかCSSクラスで透明度の値を制御（イージング処理も）

jQueryはコードが短くて覚えやすいですね。

デメリットは以下の通りです。

jQueryのバージョンによるエラーや制約に悩まされる（既存サイトの改修でエラーが出たり、バージョンのせいで使えないプラグインがあったりなど）
サイトが重くなりやすい
jQueryが使えないプロジェクトの場合は詰む（5年ほどWeb制作をやっていますが一度だけjQueryNG案件に出会いました）
jQueryを勉強してもjQueryしか書けるようにならないが、生のJSを勉強すればjQueryをはじめ他のフレームワークも理解できるようになる

0から勉強をするならjQuery？生のJavaScript？

どちらを勉強するかは、将来の進みたい道で決めればいいと思います。

Webデザインメインであったり、コーダーとして生きていくならjQueryを理解していれば十分です。

フロントエンドエンジニアとしてゴリゴリにJSを書きたい！という方は生のJavaScriptから勉強するほうが効率は圧倒的に良いです。

Googleが新たに発表した「コアウェブバイタル」

2020年にGoogleが、Webサイトを3つの指標「LCP」「FID」「CLS」で評価をして、「評価の良し悪しがSEOにも影響出るよ」と発表しました。この3つの指標のことを「コアウェブバイタル」と言います。

当サイトの計測結果

コーディングをする際は、コアウェブバイタルの3つの指標を意識しなければいけません。

LCP（Largest Contentful Paint）：サイトの読み込みスピード
FID（First Input Delay）：サイトの応答性
CLS（Cumulative Layout Shift）: サイトの視覚要素安定性

3つの指標の詳細はLIGさんの記事で丁寧に解説されています。

参考：【2021】コアウェブバイタルとは？SEO対策の方法も紹介

コアウェブバイタル計測方法

コアウェブバイタルの評価は簡単に計測できます。以下2つが主な選択肢になります。

GoogleChromeのデベロッパーツールから計測
https://pagespeed.web.dev/ で計測

GoogleChromeで計測する場合は、デベロッパーツールを起動して、Lighthouseタブから計測できます。

昨今のSEO評価の基準

昔は「正しいHTMLでマークアップをしたらSEO評価が高くなる」とよく言われていましたが、最近は違います。

よく勘違いされがちですが、正しいHTMLでマークアップをしたら、検索エンジンに正しく情報を伝えやすくなるだけで、SEO評価が高くなるというわけではありません。

SEO評価を高くするには、良質なコンテンツを作成することが最も重要です。

CSS設計

2021年現在、様々なCSS設計の手法が存在します。BEM、FLOCSS、OOCSS、SMACSS、PRECSS...どれを使うかは実装者やプロジェクトによって変わりますね。

CSS設計で重要なのは以下4点です（これは私の考えではなく、一般的に言われていることです）。

予測できる
再利用できる
保守できる
拡張できる

これらは、以下の記事で詳しく解説しています。

参考：【CSS設計】class名の決め方（命名規則）やコーディングする時の考え方を解説

書籍でしっかりとCSS設計を学びたい方はこちらがおすすめです。

<img>タグの新たな書き方

昨今は新しいHTMLタグや属性がいくつも増えました。今回は<img>タグを抜粋して紹介しようと思います。

widthとheightの属性を書くようになった
decoding="async"とloading="lazy"の登場により遅延読み込みなどが手軽になった

<img src="path/img.jpg" width="400" height="200"
  decoding="async" loading="lazy">

widthとheightの属性を書く理由は、前述のコアウェブバイタルのCLS（サイトの視覚要素安定性）のレイアウトシフト対策のためです。widthとheightの属性に画像サイズを指定することで、ページ読み込み時に画像が表示される分の高さを予め確保できるのでレイアウトシフトが起きなくなります。

webサイトにアクセスして読みたい記事のリンクをクリックしようとしたところ、
レイアウトが突然移動して広告が表示され、読みたい記事をクリックする代わりに、
役に立たない広告をクリックしたご経験はありませんか？
ページ上のその突然の動きは、レイアウトシフトと呼ばれます。

レイアウトシフトって何？SEO上、重要指標の一つCLSについて

decoding="async"は画像のデコードタイミングを、loading="lazy"は、画像の読み込みタイミングを制御できる属性です。

これらを利用することでサイトの表示パフォーマンスが向上します。しかし、使い方がそこそこ難しく、下手に使うと逆効果なのでしっかりと理解したうえで使うようにしてください。

参考：decoding="async"の使い方とloading="lazy"との違いのまとめ

Sassの LibSass（NodeSass）は非推奨になった

Sassのコンパイルにはこれまでは「LibSass（NodeSass）」を使うのが主流でしたが、これからは「DartSass」を使うようにしましょう。主な理由としては、ファイルを読み込ませたりクラスや変数などの名前空間の考え方が変わったからです。

例えば、ファイルをインポートする際に以前は@importを使っていましたが、これは非推奨になりました。代わりに@useや@forwardを使います。

// NG...
@import "header.sass"

// OK!
@use "header.sass"

これまでSassを使っていた方は、LibSass（NodeSass）からDartSassに切り替えましょう。

最近聞くようになったCSSライブラリ達

TailwindCSS、styled-components、CSS Modules、CSS in JS などのワードを最近聞くようになりました。

これらは、主にVueやReactなどのJSライブラリでCSSを書く時に用いるライブラリです。通常のコーディングで使うことはほぼありません。

（CSS in JSは、JSの中にスタイルを記述する方法の呼び方なので、ライブラリではありません）

TailwindCSSは通常のコーディングでも使え、Sassと組み合わせることもできる、ユーティリティクラスが多数用意されているCSSライブラリです。チートシートも用意されている人気のライブラリです。

公式：https://tailwindcss.com/docs/utility-first

<figure class="md:flex bg-gray-100 rounded-xl p-8 md:p-0">
  <img class="w-24 h-24 md:w-48 md:h-auto md:rounded-none rounded-full mx-auto" src="/sarah-dayan.jpg" alt="" width="384" height="512">
  <div class="pt-6 md:p-8 text-center md:text-left space-y-4">
    <blockquote>
      <p class="text-lg font-medium">
        “Tailwind CSS is the only framework that I've seen scale
        on large teams. It’s easy to customize, adapts to any design,
        and the build size is tiny.”
      </p>
    </blockquote>
    <figcaption class="font-medium">
      <div class="text-sky-500">
        Sarah Dayan
      </div>
      <div class="text-gray-700">
        Staff Engineer, Algolia
      </div>
    </figcaption>
  </div>
</figure>

TailwindCSSの書き方サンプル（公式サイトより引用）

JSライブラリ

JSのライブラリといえば、VueやReactが有名ですね。これらは比較的大きめのプロジェクトでよく使われます。

この2つの違いはこちらの記事がとても分かりやすかったです。

参考：完全に独断と偏見だけどReact vs Vue してみた

世界的にはReactが圧倒的に人気ですが、日本での求人数などを見てみるとVueのほうが人気のようです。

Nuxt.js、Next.js

NuxtはVue、NextはReactのフレームワークです。

ベースのライブラリが「VueとReact」、そのフレームワークが「NuxtとNext」のような関係性で、Webアプリ開発に必要な機能があらかじめ用意されているのが「NuxtとNext」になります。

Webアプリ開発に必要な機能は、データや状態の管理、ルーティング、API連携方法、サーバーなどが挙げられます。

参考：【2021年】Next.jsとNuxt.jsの違いを比較（将来性と求人は？）

TypeScript

VueやReactを使うならセットでよく使われるのが「TypeScript」です。

TypeScriptとは、JavaScriptに「型定義」や「クラスベースのオブジェクト指向」の概念を取り入れた言語になります。

ES6と同様、WebpackでコンパイルしたJSファイルをサイトに読み込ませます。TypeScriptの拡張子は.tsになります。

▼TypeScriptの例

// 変数宣言時に型指定をする
const title: string = 'サイトタイトル';

// Number型なのにString型のテキストを定義したらコンパイル時にエラーになる
const num: number = 'String';

SPA、SSR、SSG

これらはフロントエンド開発の「手法」です。

SPA：Single Page Application
SSR：Server Side Rendering
SSG：Static Site Generator（静的サイトジェネレーター）

SPA：Single Page Application

最大の特徴は、画面遷移を行わずにコンテンツが切り替わる点です。メニューをクリックしたら、画面の共通部分（ヘッダーフッターなど）は変わらず、コンテンツのHTMLのみを書き換えて画面を切り替えるようなイメージです。

SPAの代表例はGoogleMapです。地図上でドラッグしたタイミングで、地図部分のHTMLを書き換えています。

画面遷移に時間がかからないのでユーザー体験は大きく向上しますが、初期表示が遅い、シェアされた時のOGPが空になる、SEOに弱いなどのデメリットもあります。

SPAは、JSでHTMLを書き換えて表示させているので、ベースとなるHTMLファイルの中身はほぼ空です。このため、SEOが弱いとされていましたが、昨今の検索エンジンはJSで書き換えた内容を読み取ってくれるとも言われています（どこまで正確に読み取ってくれるかは謎ですが）。

SSR：Server Side Rendering

SPAはブラウザ側でHTMLを生成（レンダリング）していましたが、SSRはサーバー側でレンダリングを行います。

サーバー側でレンダリングを行うので、ブラウザに表示する時には「中身がしっかりとあるHTML」を返します。このため、検索エンジンもHTMLを読み取ってくれるので、SPAよりSEOが強いとされています。

SSG：Static Site Generator（静的サイトジェネレーター）

ビルド時（リリース時やCMS部分更新時など）にHTMLファイルを生成して、そのファイルをブラウザ側に表示させます。

SPAやSSRはリクエストするたびにHTMLを生成しますが、SSGはリクエスト時に事前に生成したHTMLを返すだけです。ただの静的ページを表示しているようなイメージです。

SSGは静的HTMLを表示させているのでサイトパフォーマンスが高いです。

しかし、デメリットも当然あります。ページ量が多いとビルド時間がかかったり、データの更新のたびにビルドを行うので更新頻度が多いサイトには不向きなどが挙げられます。

ヘッドレスSMCのmicroCMS、静的コンテンツのホスティングサービスのNetlifyなどがセットで使われることが多いです。

参考：microCMS + NuxtでJamstackブログを作ってみよう

ノーコードでの開発

最近はノーコード（コードを書かないでサービスを作る）での開発も積極的に取り入れられています。

WordPress
ブログなどを手軽に作れる超有名なCMS。プラグインや日本語解説記事が豊富。
有料テーマだとSWELLとSnow MonkeyがSNSを中心に一定の支持層を得ている印象。
Movable Type
機能はWordPressに近いがカスタマイズの難易度が高い。公式ドキュメントが豊富。マイナー。
STUDIO
デザイン性の高いCMS。STUDIOの事例集は圧巻。「これをノーコードで作ったの！？」ってなるので是非見てください。
最近のトレンドで多くの企業が導入するようになった。
Shopify
ECサイトを手軽に構築できる。BASEやSTORESよりカスタマイズ性が高い。liquidというShopify専用言語でカスタマイズができる。WordPressを理解していればliquidもすぐに扱えると思う。

他にも昔ながらのWixやペライチ、エンジニアに定評のあるWebflow、最近日本語化されて話題のNotionなど、ノーコードは数え切れないほどあります。

フロントエンド開発とサーバーサイド開発の分離

これまではフロントエンド開発とサーバーサイド開発を同じファイルで同時に行っていました。これには問題点がいくつかあります。

フロントを修正したらサーバーも修正しなければいけない（逆のパターンも）
開発ファイルがフロントもサーバーも同じなのでミスが起きやすい
どちらかの開発が遅れると、もう片方の開発にも影響が出る

これらの問題を解決できるのが、昨今の流行り？のフロントエンド開発とサーバーサイド開発の分離です。

フロントエンドに表示する情報はAPI経由で取得します。

なので、フロントエンドは見た目の開発のみ、サーバーサイドはAPI開発のみに専念できます（お互いが違う分野のことをやらなくていい）。

また、開発ファイルはフロントエンドとサーバーサイドで完全に別になるので、双方のミスも起きにくく、お互いの開発の進捗に囚われずに開発を進められます。

APIベースの開発になるので、作ったAPIを流用してWebサイト以外のアプリなどを作ることもできます。

フロントエンド開発とサーバーサイド開発を分離するメリットはこちらの記事で詳しく解説されています。

参考：APIファーストで開発する7つのメリット

サーバーサイドエンジニアが知っておきたいフロントエンドのこと

サーバーサイドエンジニアの方でもプロジェクトによっては、HTML/CSS/JavaScriptを書くことがあると思います。その際に、これだけは覚えてほしい・理解してほしいということをまとめてみました（個人的意見と願望）。

クラス名や変数名は適当に付けない（DB設計時のテーブル名やカラム名みたいにちゃんと付けてほしいです...）
画像のファイル名やディレクトリ構造は分かりやすくする
画像は必ず圧縮する（未圧縮だとサイトが重くなります）
コードのインデント（特にHTML）は綺麗にする
floatは使わないで...今はflexやgridという便利なCSSがあります
昔からこの業界にいるエンジニアは、floatでCSSの知識が止まっている場合があります...専門外なのでしょうがないですが、今は便利なCSSがたくさんあるので、もし周りにfloatを使っている方がいたら優しく教えてあげましょう

まとめ

フロントエンド開発の手法はたくさんあります。働く環境によっては、他では当たり前なことを全く知らなかった…ということも十分起こりえます。定期的にオープンな勉強会やセミナーなどに参加して情報をキャッチアップするのもいいと思います。

HTML/CSSのベースコーディングをもっと学びたい方は、CSS設計やWebpackなどのモジュールバンドラーを勉強するのがおすすめです。将来ゴリゴリのフロントエンド開発をやりたい方は、VueやReactを中心に勉強するのがいいでしょう。