本記事の対象読者と前提
本記事は、企業サイト、オウンドメディア、技術ブログなど、静的コンテンツを中心としたWebサイトの構築を検討している方を対象としている。
一方で、本記事はすべてのWebシステムに対して Astro + React の採用を推奨するものではない。
特に、
- 高頻度な状態更新を伴うリアルタイムアプリケーション
- 認可制御を前提とする業務システム
- 複雑な画面遷移や状態管理を持つSaaS
- 管理画面が主役となるシステム
などについては、本記事で扱う前提とは大きく異なる。
これらのシステムでは、
SEOよりも認証認可、
コンテンツ配信よりも状態管理、
静的生成よりもアプリケーションとしての振る舞い
が重要になる場合が多い。
そのため、本記事の技術選定理由をそのまま適用できるとは限らない。
本記事で述べる内容は、DataLinerが運営する表玄関および語り部の座のような、
静的コンテンツが中心のサイト
を前提とした技術選定の記録である。
本記事で参照する主な情報
本記事では、AstroおよびReactに関する技術的特徴について、以下の一次情報を参照している。
Astro
Astro Documentation
参照内容
- Astroの基本思想
- Content-focused Website の考え方
- Zero JavaScript by Default
- Islands Architecture
Astro Islands Architecture
https://docs.astro.build/en/concepts/islands/
参照内容
- Islands Architecture の概要
- 必要なコンポーネントのみをクライアント側で動作させる仕組み
React
React Documentation
参照内容
- Reactのコンポーネントモデル
- クライアントサイドUI構築
- Reactエコシステムの基本思想
1. DataLinerが実現したかったこと
1.1 まず欲しかったのはコンテンツだった
表玄関と語り部の座を構想した当初、
私が作りたかったのはWebアプリケーションではなかった。
作りたかったのは、
- DataLinerという会社を伝える表玄関
- 技術や考察を発信するメディア
である。
つまり、
本質はコンテンツ配信であった。
ユーザーごとに画面を変える必要もない。
複雑な業務処理もない。
リアルタイム更新もない。
まず必要だったのは、
高速に表示できること
検索エンジンに評価されること
長期間運用できること
だった。
1.2 しかしReactは捨てたくなかった
一方で、
私はReactを完全に捨てたいとは考えていなかった。
現代のWeb開発において、
Reactのエコシステムは非常に成熟している。
利用できるライブラリも多い。
開発者人口も多い。
将来的な拡張性も高い。
実際、表玄関や語り部の座においても、
検索機能
目次
インタラクティブなUI
将来的な会員機能
など、
一部に動的な振る舞いが必要になる可能性があった。
つまり、
静的サイトの強みも欲しい。
Reactの資産も活用したい。
という二つの要求が存在していたのである。
1.3 DataLinerにおける制約
技術選定を行う上で、DataLinerにはいくつかの制約が存在していた。
- 開発者は実質1名である
- 運用保守も同一人物が担当する
- 企業サイトおよびメディアサイトが主目的である
- SEOを重視する
- コンテンツ更新頻度は週数回程度を想定する
- 将来的に検索機能や会員機能などの動的要素を追加する可能性がある
- 過度に複雑な構成は避けたい
つまり、
高機能なWebアプリケーションを構築することではなく、
少人数でも長期間維持できることを重視していたのである。
2. Astroを選んだ理由
2.1 デフォルトを静的にしたかった
私がAstroを採用する上で最も魅力を感じたのは、
Astro公式ドキュメントでも掲げられている
「Zero JavaScript by Default」
という思想だった。
多くのフレームワークでは、
クライアントサイドJavaScriptの実行を前提としている。
一方Astroは、
まず静的HTMLを生成することを基本とし、
必要な箇所だけを動的化する。
この考え方は、
DataLinerが目指していたコンテンツ中心のサイトと非常に相性が良かった。
2.2 コンテンツ中心のサイトとの相性
表玄関や語り部の座は、
記事を読むことが主目的である。
読者は、
記事を読む。
プロフィールを確認する。
事業内容を見る。
問い合わせを行う。
これらの大半は、
サーバーサイドで生成されたHTMLだけで成立する。
つまり、
最初から大量のJavaScriptを読み込む必要がない。
Astroは、
こうしたコンテンツ中心のサイトと非常に相性が良かった。
3. Reactを組み合わせた理由
3.1 必要な場所だけ動的にする
Astroには Islands Architecture という考え方がある。
静的なページの中で、
必要な部分だけをReactなどで動かす。
私はこの考え方を高く評価している。
なぜなら、
静的サイトと動的サイトの二者択一ではなく、
両者の長所を組み合わせられるからである。
この考え方はAstroが提唱する Islands Architecture に基づいている。
ページ全体をクライアントサイドアプリケーションとして構築するのではなく、
必要な箇所だけをインタラクティブにする。
DataLinerにおいては、この思想が静的コンテンツ中心という要件と一致していた。
3.2 技術的負債を減らしたかった
DataLinerは大企業ではない。
開発チームが何十人もいるわけではない。
だからこそ、
複雑な仕組みを増やしたくなかった。
React単独で構築すると、
不要なクライアント処理まで抱える可能性がある。
一方、
完全な静的サイトにすると、
将来の拡張性が失われる。
Astro + React は、
その中間に位置していた。
必要十分な仕組みを維持しながら、
将来の拡張にも対応できる。
そのバランスが魅力だった。
4. DataLinerにおける技術選定の考え方
4.1 技術は主役ではない
私は、
技術は黒子であるべきだと考えている。
利用者が評価するのは、
AstroでもReactでもない。
コンテンツであり、
体験であり、
提供される価値である。
技術はその価値を支えるために存在する。
だから私は、
まず技術から選ばない。
まず実現したいことを考える。
その結果として、
技術を選ぶ。
今回の Astro + React も同じである。
4.2 なぜAstro + Reactだったのか
DataLinerが実現したかったのは、
静的コンテンツを高速に届けることだった。
しかし同時に、
将来的な拡張性も確保したかった。
Astroは静的サイトとしての強みを持つ。
Reactは動的UIとしての強みを持つ。
そしてAstroはReactを必要な場所だけ利用できる。
その結果として、
DataLinerでは Astro + React を採用した。
Astroを使いたかったからではない。
Reactを使いたかったからでもない。
実現したいことを整理した結果として、
Astro + React という選択に辿り着いたのである。
本記事の適用範囲
本記事で紹介した技術選定は、
DataLinerホームページおよび語り部の座という、
静的コンテンツ中心のサイトに対して行われたものである。
そのため、
- SaaS
- 業務システム
- リアルタイムアプリケーション
- 管理画面中心のシステム
に対して同じ結論になるとは限らない。
技術選定において重要なのは、
Astroが優れているか、
Reactが優れているか、
ではない。
自分たちが何を実現したいのか、
そしてどのような制約の下で運用するのかを整理することである。
おわりに
本記事では、DataLinerホームページおよび語り部の座の構築において、
なぜ Astro + React を採用したのかを紹介した。
重要なのは、
Astroが優れているか、
Reactが優れているか、
ではない。
まず考えるべきなのは、
何を実現したいのかである。
技術選定とは、
技術を選ぶことではない。
実現したいことを整理し、その結果として適切な技術へ辿り着くことである。
DataLinerでは、その考え方に基づき Astro + React を採用した。