なぜ私はGatsbyでブログを作っているのか

thumbnail

そろそろブログの依存ライブラリが古くなってきたので更新を考えていて、そのときについでにそもそも作り直すかということを検討していた。 で、2022 年における SSG FW は何が良いかと調べていたところ、結局 Gatsby を選ぶことになりそうなので、自分の要望や調べたことについて書いておく。 ちなみに現時点での選択肢は、Gatsby, Next, Astro, 11ty だ。

SSG を前提

まずブログは静的サイトとしてホスティングしたい。これは SSR させると Node を動かすプロセスが必要となり、コストが嵩むし TTFB 的にもよくないからである。Vercel を使えば TTFB 対策の CDN 込みでコスト面では許容範囲かもしれないが、料金プランの改定はいつあってもおかしくないと思っているので、依存したくはなかった。静的ホスティング一択である。

tsx を使いたい

自分が思う最強のテンプレートエンジンは JSX で、それも型のついた TSX である。とした場合、いまのところ SSG FW としては Gatsby, Next のどちらかになる。

画像の最適化

結構雑に画像を入稿したいので、画像の最適化も必須である。これがなければ毎回画像をトリミングしたり画質を落としたりしないといけなく面倒である。imgix を使う手もあるが、外部依存だしコストもかかるかもだし採用は見送った。

そして現状、SSG と一緒に画像を最適化できるのは Gatsby である。標準機能としてできること、さらにはマークダウン内の画像まで最適化がプラグインでサポートされるので、この手のタスクは Gatsby が得意である。他の FW はできなさそう、もしくはかなり hack しないといけなさそうだった。Astro は v1 で可能性が出たが、画像を md 内の相対パスから読み込んで最適化ができず、独自コンポーネントを使わないといけなさそうで、portability が良くなさそうなので見送った。

プラグインシステムはそこまで嫌いではない

Gatsby に対する dis の一つにプラグインシステムがあると思う。しかし私は実はあまり嫌いではない。むしろプラグインを入れるだけでいろいろな機能が使えるようになるので楽である。もちろん長期的なメンテナンスは期待できず、Gatsby のメジャーアップデートで壊れることも多々あるが、いま作っているのはただのブログであり、正直いくらでもリカバーが効くので、プラグインシステムはどちらかというとプラスの側面の方が強い。仕事で使うかという話であれば、少し考えるかも。

型とバリデーションに不満がある

Gatsby の GraphQL 結果に対しては、codegen 経由で型をつけられる。なので、いろいろな箇所に型をつけられて回避方法は悪くない。しかしほとんどが Optional である。なので zod のようなものをビルド時に通してしまいたい。ただ Gatsby には getStaticProps のようなものがないので、ビルド時に検証して落とすことができない。ランタイムで JS が動かないことを前提にコンポーネントの中で走らせても良いが、もし state 持たせて再レンダリングさせるとかを将来したくなると、毎回バリデーションが走ってしまうのでやりたくない。ここは唯一の不満。(と思ったけど props 監視 の useMemo で十分な気がしてきたな?)

まとめ

なんだかんだで Gatsby が一番好きかも