ブログをHexoからGatsbyに移行した
自作ブログをHexoからGatsbyに切り替えた話。
ブログをGatsbyからAstroに移行した
本ブログのSSGを Gatsby から Astro に移行した❗ ついでに Tailwind から Bulma に移行した❗
技術的なことは別記事でつらつら書くとして、 ここでは見た目とかの使い勝手の部分について書いていくよ。
Gatsbyのときとの見た目比較
トップページの比較
トップページはこんな感じ。
Bulmaのデフォルトスタイルを使いまくってるので、 配色的にはイケてる感じになったと思う。
文字サイズは小さくなったね。 っていうか前がデカｽｷﾞｨ❗
ナビゲーションもイケてる感じになった。 ここはBulmaの Hero レイアウトを最大活用してる。
Gatsbyのときは記事が1つが横幅いっぱい使ってたけど、 Astroでは後述のカードレイアウトと同じになった。 単に作成の手間を省力化したかっただけ。 今回のテーマは省エネだから😎
カードグリッドページの比較
カードグリッドページ（タグページ）はこんな感じ。
良くも悪くも無難になった。
Gatsbyのときは縦長ヒーローイメージ対応とかしてたけど、 あれは保守性が最悪なので、さっさとやめるべきだったね。 Gatsbyでは横長ヒーローイメージのみに対応。 既存の縦長ヒーローイメージは画像の上側にフォーカスして、顔だけ映るように調整してる↓。
あと、カードのサイズが小さくなった。 これはBulmaのデフォルトサイズだったと思う。 後で大きくするかも。
記事ページの比較
記事ページの比較…はできない。 Gatsbyのときのスクショ撮り忘れたｗ
比較はできないけど、Astro単体のスクショはある。 まずは記事ページの最上部↓。
いつも通りヒーローイメージを大きく表示。 タグの位置は迷ったけど、ヒーローイメージの下部に配置した。 記事本文ですぐに画像が始まるので、ヒーローイメージと記事本文の間をなるべく距離をあけて自然に見えるようにしたかった。
記事本文は↓。
GatsbyやHexoのときに作った記事には一応Cautionを表示してる。 微妙に互換性がなくなって、不自然な部分も残ってるからね。 こういうコンポーネントはAsideというらしくて、 これが綺麗に表示できるのもAstroとBulmaのおかげ。
互換性がなくなってる部分の一例が『レビュー続き』の見出し。 Gatsbyのときは、記事冒頭とそれ以外が概念的に分かれてたけど、 Astroではなくなった（なくした）。
オミットされた項目
- アーカイブページ
- 不要と判断。今日日、ブログ単位で回遊する人はいないと思う。
- タグクラウドで全タグ表示
- 無数のタグはSEO的に悪影響らしいのでやめた。一旦トップ20に絞ったが、まだ変える可能性がある。
- 画像のリンク
- 不要と判断。スマホもPCも拡大すればいいし、PCは十分に大きく表示できるはず。
- 記事ページ最下部の前後記事へのナビゲーション
- 不要と判断。フィギュア記事からプログラミング記事に飛びたい人はいない。
「なんでGatsbyから移行したの❓」
主に↓の2点が理由。
- ビルドやプレビューが遅い
- 構造が複雑すぎる
ビルドやプレビューが遅い
昨今のWeb系ツールは どれも当たり前のように Vite のような高速なビルドツールを使っている。 が、Gatsbyは使ってないので遅い。
AstroはViteを使っているのですこぶる早い。
astro dev でプレビュー用のサーバーが一瞬で立ち上がる。
記事を編集して保存した瞬間にWebページがリロードされるので、
執筆してて非常に快適。
構造が複雑すぎる
Gatsbyの開発から1年以上たった現在、 ソースを見直してみたが、正直メンテできないｗ
まず、GraphQLが複雑すぎる。 機能的にはすごかったと思うんだけど、 Markdownの記事と画像を取得できればいいだけのブログにとってはtoo muchすぎる…😩
スキーマ定義みたいなのもしてた記憶があるけど、 今見てもさっぱり分からんね。
もう1つの複雑ポイントはReactだね。 ブログってインタラクティブに操作するものがほとんどないから、 Reactはtoo muchだと思う。
まぁ、React（JSX）も箱としてしか使ってないから、 使い勝手は逆にシンプルっちゃシンプル。 でも、AstroがよりバニラなHTMLに近くて、それで十分なんだから、 使いこなせてないReactに依存するのはイケてないよなって思ってた。
「なんでAstroへ移行したの❓」
イケてるから。
ネットの評判を見てると、Astroは良いぞオジサンが大量発生してたんだよね。 だいたいが「React/Vue (Next/Nuxt) ってtoo muchだよな…。」って言ってたと思う。 自分の感覚ともマッチしてたから、俄然興味が湧いてたわけ。
そもそも、やりたいことに対して最小限の技術を使うっていう思想が良いよね。 大事だと思う。
「Astroでできることは❓」
公式サイトを見てもらうのが一番として、当ブログで大事なのは↓かな。
- Markdownで記事が書ける。
- 実際にはMDXを採用
- コンポーネント指向でサイトが作れる。
- CSSの影響もコンポーネント内に閉じこめれる。
- 記事執筆中のプレビュー（
astro dev） - 画像の最適化
- RSSフィードの生成
- サイトマップの生成
- タグページの生成（Dynamic routes）)
- TypeScript
詳細は気が向いたら別記事にして書く。
「Astroでできないことは❓」
バニラMarkdownでの画像の最適化
AstroのデフォルトではバニラMarkdownの画像の最適化はできない。
バニラMarkdownでは↓のように画像を記載する。
これをAstroでビルドしても、WebPに変換したり、
レスポンシブ対応用に複数解像度を生成したりはできない。
hoge.jpg がバンドルされるだけ。
この問題は画像メインの当ブログとしては致命的だったので、MDXを採用して回避した。 MDXはMarkdown中にスーパーセットで、任意のコンポーネントをMarkdown中に記載できる。
具体的には↓のように記載している。
import PostsImage from "@components/PostsImage.astro";
ほげほげ。
<PostsImage
src="./images/screenshot-astro-post-2.png"
alt="Astroで作ったブログのスクリーンショット。縦長ヒーローイメージのポストのカード。"
/>
ふがふが。
<PostsImage.astro> が自作の画像コンポーネント。
そこで画像の最適化をするようにしている。
なお、他の実現方法としては↓がある。
- サードパーティのプラグインを使う。
- Markdownの解析プラグインを使って、画像要素生成時にフックして自作コンポーネントに変換する。
いずれもメンテできるか怪しい複雑さだったので採用を断念した。良くわかってないのもある。
「Bulmaどう❓」
良いぞ。
やっぱりある程度コンポーネントレベルでスタイルが定義されてるのが楽ちん。 TailwindCSSは自由度が高いけど、 コンポーネントとしてまとまったスタイルを当てるのはちょっと複雑だった。 （ Flowbite をちゃんと使いこなせればまた印象が変わるかもしれない。）
あと、機能が少ないのが逆に良い。 Bulmaが想定してるクラスの組み合わせから外れると、 途端に見づらくなったりするんだけど、原因が分かりやすいんだよね。 「余白設定してるのこいつしかありえないよな」とか 「文字が薄いのはこのコンポーネントクラスのせいだな」とか、 予想がつきやすい。
そうして原因がわかったあとも、対策のためのカスタマイズがしやすい。 Bulmaが定義済みのCSS変数を書き換えるだけだったり、 クラスの内容を書き換えるだけで、だいたい思い通りになる。
あ、最大のメリットは、きれいなCSS構造を学べることかも。
TailwindCSSで作ってたときはセオリーも何も知らずに作り込んでたから、
かなり複雑になっちゃってた気がする。
Bulmaの実装を見ながらサイトデザインしていくと、
クラスで指定していCSSプロパティの少なさに驚く。
「シンプルに margin 使うだけで済むんだな〜」ってことが分かってきたりするので、良い勉強になった。
あとがき
う〜ん、だいぶスッキリした。 これでブログ記事が書きやすくなったので、 技術記事、フィギュア記事、AI記事あたりをもっと書いていけると思う。
とはいえ、気が向いたら書くの精神は変わってないので、気長に待っててね〜。
おまけ: HexoからGatsbyに移行したときの記事
