ブログを Next.js へ移行しました
元々は GatsbyJS で作られていたこのブログを、Next.js で書き直して復活させました。 放置している間にもいくつか記事にしたい事柄があったのですが、元の仕組みでは記事を書く気が起きず、結果的に 1 年近く放置することになってしまいました。
この記事では「なぜ GatsbyJS から移行したのか」と「他のフレームワークを比較した結果」、そして「最終的な技術スタック」について説明します。
なぜ GatsbyJS から移行したのか
このブログは元々は GatsbyJS で書かれていました。 当時の自分が GatsbyJS を選んだ理由は、恐らく慣れていたからだと思います。
GatsbyJS 自体は別にそんなに悪いとは思っていません。 GraphQL で依存するリソースを記述するという考え方はビルドを最適化する上でそこまで間違った方針ではないと考えています。 最近はやや JavaScript エコシステムの進化に追い付いていないような雰囲気もありますが、別に最先端を追わなければいけないわけじゃないので、そこまで大きな問題ではないはずです。
では旧ブログの実装のなにが問題だったのかというと UI フレームワークに Chakra UI を使ったことと、パッケージマネージャーに PNPM を選んだことが問題となっていました。 Chakra UI は tailwindcss の影響を受けたユーティリティ指向な React の UI フレームワークです。マージンなどを React のプロパティで設定できるのが便利だった気がします。 PNPM はパッケージマネージャで、Yarn や NPM などと比べて高速に依存関係の解決を行なえるのが魅力でした。
これらが、GatsbyJS と微妙に相性が悪いのが問題となっていました。
例えば、Chakra UI 公式のプラグイン (@chakra-ui/gatsby-plugin) があるのですが、自分が使った当時は過渡期なのか最新版の Chakra UI と組み合わせるとエラーが起こるし、それらを解決してもテーマを切り替えてからブラウザをリロードすると、一瞬デフォルトのテーマのスタイルになってしまう問題は最後まで解決できませんでした (なので途中でダークモードの切り替えを無効にしています)。
また、PNPM も GatsbyJS と相性が悪く、GatsbyJS と使うにはプラグインを入れる必要があります (gatsby-plugin-pnpm)。
こういった問題がなかなかにストレスフルで、旧ブログにはあまり触れたくなく、いつか作り直したいという気持ちが高まっていました。
他のフレームワークを比較した結果
あくまでブログを作りたかったので、Docusaurus とか VuePress みたいなドキュメントジェネレータはそもそも検討していません。 あしからず。
GatsbyJS
そもそも GatsbyJS 自体はそんなに悪いと思っていないのなら、問題のあるライブラリなどを外して GatsbyJS で作り直せばいいんじゃない？ という意見もあるかと思います。
それでも良かったのですが、GatsbyJS はビルドに Webpack を使っていて、2022 年の開発体験としては Webpack の速度はイケてないな、という気がしたので、今回は GatsbyJS 以外の選択肢を検討することにしました。
Astro.build
Astro.build はビルド時に JavaScript などを実行して結果の HTML のみを配信することで、JavaScript なしのサイトを構築できる静的サイトビルダーです。 Snowpack のところが作っているのですが、最近ビルドが Vite に切り替わったというのも注目のポイントです。 他にも、スクロールを監視してコンポーネントが描画領域に入ったところで JavaScript をロードして実行するようにできたり、かなり先進的な特徴を持ったフレームワークのように思います。
少し使ってみて良かったと感じたところは、React や Vue、Svelte など好きなライブラリでコンポーネントを記述して、組み合わせて使えるところがまず面白いと感じました。
それと、Astro.build 独自の astro ファイルのシンタックスも、スクリプト部分のインデントが 1 つ減るという意味で悪くないなと思いました。
しかし、npm init したあとのファイルをエディタで開くと、エディタではエラーになるけど実際はビルドできる、といったエコシステム周りで不十分なところがあったり、
とくに致命的なところとして、組込みの Markdown サポートでは数式を含むものを上手く扱えないという問題がありました。
後者は自前で Markdown をパースして追加すれば問題を回避できそうですが、そこまでやる必要はない気がしたのと、全体的にまだ未成熟な印象がしたので、今回は採用を見送ることにしました。
SvelteKit
SvelteKit は Svelte 版の Next.js みたいなやつです。
そんなに際立った個性があるようには思わないのですが、Svelte を使いたいのであれば悪くない選択肢だと思います。 retest の開発で使ってみて、そこそこ使えるなという印象を受けました。
今回採用しなかったのは、正直に言うと Svelte の書き方にそこまで魅力を感じないというのが一番の理由です。 基本的に状態を更新する部分は隠蔽するべきじゃない、という意見があります。
Nuxt
Nuxt は Vue 版の Next.js みたいなやつです。 昔は Next.js よりも機能が多くて色々やれた気がするのだけど、今はそんなに変わらない気がします。
選ばなかった理由は Vue よりも React を使いたかったからです。 でも最近 Vue 書いてないな‥‥。
Next.js
というわけで Next.js です。
選んだ理由としては、昔使ったときは微妙だった、というかフレームワークとしてもライブラリとしても中途半端な印象だったのだけど、最近はそうでもなさそうな気がしたので、触れてみたいと思ったからです。 他にも tailwindcss を使ってみたかったというのもあります。
最終的な技術スタック
そんなこんなで Next.js でブログを作り直しました。 実装的には別にすごいことはしていません。 実装の Pull Request はこちらになります。
使ったライブラリは次のような感じです。
tailwindcss はユーティリティ指向の CSS フレームワークで、最近というかここ 1 年くらい流行っている気がします。 daisyUI は tailwindcss 上の UI コンポーネントライブラリで、細かいところを tailwindcss で調整できるのがいいところだと思います。 デザインは daisyUI にあるものを優先して使いつつ、細かいところは tailwindcss で整える、というようにしていきました。 なんか昔よりも tailwindcss が使いやすくなった気がしたけど、多分それは自分が CSS に慣れただけな気もしています。
markdown-it は Markdown の描画に使いました。 remark でも良かったのですが、remark のカスタマイズ性をフルに使うことってないしな、と思って markdown-it にした次第です。 あと remark はちょっと遅いという問題もあります。 markdown-it のプラグインとしては markdown-it-shiki と markdown-it-texmath を使いました。 markdown-it-shiki はシンタックスハイライトに Shiki を使うようにするもので、markdown-it-texmath は KaTeX を使って数式を描画するやつです。
サイトのデプロイ先は普通に GitHub Pages にしました。 Cloudflare Pages とかも面白そうだなと思ったのですが、慣れてる方がいいだろうし、なんか色々あって結局 GitHub Pages に戻ってる気がしたからです。
この記事は以上になります。 最後まで目を通していただきありがとうございました。