mottox2 blog

なぜSPA技術でウェブサイトをつくるのか?

devspa

ここ最近、SPAを作るフロントエンドエンジニアを中心に、アプリケーションではないウェブサイトもReactやVueで作る動きが活発になってきました。

  • そもそもなぜReactやVueを使ってウェブサイトを作るのか?
  • これらの技術を使うことによって何が解決するのか?

本記事ではそういった問いに対する自分の考えを示します。

SPA以前のウェブサイト制作

注)現在進行系でも非SPAなウェブサイト制作が主流です。

現在主流な制作手法は、WordPressに独自のテーマを実装して制作する方法です。
PHPなどで動的にHTMLを生成し、大きなCSS・JSが一枚というケースが多いです。

もちろん、モダンフロントエンドを取り込んでいる場合もあって、次のような工夫をしていることが多いです。

  • SCSSのようなメタ言語でCSSを記述し、保守の手間を減らす。
  • webpackなどのバンドラーを利用する。

ただ、この場合のJSはjQueryが使われることが多く、jQueryプラグインにはnpm経由で利用できないものもあって辛い印象を持っています。

コーポレートサイトやWordPress製のブログといったウェブサイトでは、CDNを利用してファイルを高速で配信しているサイトもありますが、フロントエンドのレンダリングの速さはあまり重視されていないように思えます。

そもそもなぜSPA技術でウェブサイトを?

CSS系の問題を一挙解決

正直のところ、CSSは難しい言語だと思います。
スタイルは子要素へ受け継がれていく、セレクタによる優先度、未使用部分を発見することの困難さなどの原因からCSSは肥大化していきます。

CSS肥大化によって、重複したスタイルが出現して保守が大変になる、ページ読み込み速度が遅くなっていくなどの問題が発生します。

保守が困難という問題に対抗するためにBEM, OOCSS, FLOCSSなどの命名手法が採用するなどの取り組みがあります。ページ読み込みを高速化するには、ページ読み込み時に見える範囲(above-the-fold)のCSSをHTMLに埋め込むの手法が有効です。これらのCSSを検出し、埋め込むためのwebpackプラグインなどが存在しますが、いまいち認知はされていないようです。

一方、React, Vueといったライブラリではコンポーネント内にCSSを書く方法でこれらの問題を避けています。

JSが保守しやすくなる

JavaScriptでDOMにイベントを付与するようなコードが圧倒的にわかりやすくなります。
いわゆる「宣言的」に書けるから嬉しいといった話です。

参考: 宣言的UI - Speaker Deck

DOMを直接触るようなコードでは、他人が書いたコードを読むのがかなりしんどいです。(個人の感想です)設計によって苦しさを緩和することもできますが、記述は圧倒的に増えます。

Before

jsx
<div id='app'>
  <button id='trigger'>Click!</button>
</div>

<script>
const trigger = document.getElementById('trigger')
trigger.addEventListener('click', () => {
  const newEl = document.createElement('div')
  newEl.textContent = 'hello world'
  document.getElementById('app').appendChild(newEl)
  newEl.addEventListener('click', onClickHoge)
})

After

jsx
const App = () => {
  const [isActive, setActive] = useState(false)
  const onClickButton = useCallback(() => setActive(true), [])
  const onClickHoge = useCallback(() => {}, [])
  
  return <div>
    <button onClick={onClickButton}>Click</button>
    {isActive && <div onClick={onClickHoge}>Hello World</div>}
  </div>
}

ライブラリ管理の話

jQuery系のプラグインはパッケージマネージャで使えない場合があり、そういった場合minfyされたJSファイルをプロジェクト中に置くことになるでしょう。
開発者や環境にもよりますが、バージョンアップがされづらく、最悪の場合ソースが直接書き換えられるという問題もあります。(実際に経験があります。)また、バージョンアップされないライブラリのために、jQuery本体のバージョンもあげられないというケースも存在します。

ReactやVueの開発ではnpmがほぼ必須といってもいい環境なので、今どのバージョンが使われているかははっきりわかりますし、(よっぽどのことがない限り)直接ソースが書き換えられることはないでしょう。
バージョンアップには手間はかかりますが、パッケージマネージャがない状況と比べれば圧倒的に楽です。
素直にSPA開発で発達した開発手法に乗っかりましょう。

DX系・環境構築の話

サイトを制作する際に、開発環境を構築する必要があります。
サイトを制作する前にgulp、gruntなどといったツールを使って、開発するための環境を整備することが必須とも言える状況でした。また、これらの環境は属人化しやすく他の人が引き継ぎにくいといった課題もありました。

SPA系のフレームワークでは、これらのタスクに加えてJS, CSS系の最適化も自動で行ってくれることが多く、手間なく環境を整えられます。
また、npmで配布されているSPA系のライブラリを簡単に使える、バージョン管理など開発フローに載せやすい、TypeScriptを使って開発するなど開発者として開発しやすい環境を手間なく用意できます。

作って終わりではなくなった

個人の感想に近いですが、近年作って終わりではなく、公開してからも継続して運営するようなものが増えてきたと思います。
つまり、今まではバージョン管理ツールに載せず、汚いコードで乗り切るといったことも可能でした。ただ、これからはWebサービス開発で利用しているような開発手法を利用することが重要だと感じています。

React, Vueを利用する上ではフレームワークを利用することでwebpack, babelといったツールの設定が隠蔽され属人性が減り、規約が存在することで設計のブレを減らせます。
今後はフレームワークという巨人の肩にのり、ウェブサイトを作っていく手法が流行っていくといいと思っています。

まとめ

この記事で示したものはかなり偏った考えかもしれません。WordPressで使いたいテーマがあるということであれば、そちらを利用するといいでしょう。
ただ、自分でしっかりデザインしたい、テーマ以上の品質を保ちたいということであれば、製作者のレベルにもよりますがReact, Vueで作ったほうがよりよいものができると思います。

また、このあとに「なぜReact, Vue単体ではウェブサイト開発が行われないのか」というテーマがあり、サーバーサイドレンダリング(SSR)・静的サイトジェネレーター(SSG)というトピックに派生していきます。

よりよい環境が普及することを願っています。

B!
design

SketchからFigmaに乗り換えるにあたり考慮したこと

自分は2015年ぐらいからSketchというMac専用のデザインツールを利用してきました。しかし、最近はFigmaというツールをよく聞き、知人から(とくに@takanorip氏)も評判がいいので触って

figma
dev

TypeScriptで始めるNext.js 1: セットアップ

日本国内で、SPAをベースにしたフレームワークはVueベースのNuxt.jsが有名です。しかし、Nuxt.jsはNext.jsというReactをベースにしたフレームワークを参考に作られたものです。

dev

GitHub Actionsをスケジューラとして利用する

GitHubが提供しているGitHub Actions(beta)は「ソフトウェアワークフローを簡単に自動化できる」とあります。その中にcron形式でワークフローを実行することが出来る仕組みがあり、定