Gatsbyからhugoに切り替えた話

1年ごしの投稿です。で、GatsbyからHugoに乗り換えました。

なぜかというと、直接の原因はGatsby環境が壊れちゃったからです。

GatsbyはsharpというJavaScriptでは有名な画像ライブラリを、プラグイン経由で呼び出して画像のサイズ変更などの処理をします。これがGatsbyバージョンアップしたら動かなくなっちゃったんですよね。どうしてかは調べてもわからなかったのですが。

それ以外にも不満があったのでこの機に乗り換えることにしました。

Gatsbyで困ったこと

Gatsbyで困っていたのは大きく2つあり、1つは全体の動作に保証がないこと、もう1つはコンテナで固められないことでした。

全体の動作に保証がない、と言うのは、プラグインやパッケージ管理システムでいろんな機能を実現すると、組み合わせて動かした時にコンフリクトが起きたり、なぜか動かない、と言うことが起こるんですよね¹。dockerが生まれて普及した理由の1つですね。

それと、本体とプラグイン分かれてるとメンテナンスの責任も分散してしまいます。プラグインが本体バージョンに追随してくれるかは運次第で、結果的にバージョンアップに誰も責任負わなくなっちゃうんですよね。

こういうことが起きるので、コンテナで環境を固めておきたいとなるんですが、Gatsbyで環境作ってみるとこちらもうまくいきませんでした。 コンテナ作る時にはdockerfileで必要なパッケージをインストールして、その中で追加のインストールはしない、と言うのがセオリーです。しかしGatsbyはビルドする時に自分でプラグインをインストールしないと認識しないらしく、あらかじめインストールしたものを使ってビルド、ということができなかったんです。

いろいろ妥協して使ってたんですけど、結局最後にこのダメなところがトドメになってしまいましたね。そもそもWordpressギブアップしたのも維持管理が面倒だったからで、やはり維持管理が面倒なものは続きません。それが筆者のような面倒くさがりならなおさらです。

Hugoはまさにこの2点が解決されている、と言うのが大きいです。1つのバイナリで機能が実現されていて、公式がその機能を保証してくれます。SSGの人気ランキングもだいぶ変わっていて、いまは2位のようですね²。そしてビルドが速い！実際に動かしてみて驚きました。

この環境をコンテナにして自分のどのデバイスからでも触れるようにしようとしてめちゃくちゃ苦労したのですがその話はまた別途。

Gatsby触って得られた経験

ただGatsbyを使って損したか、というとそういうわけではありませんでした。とくに自分はフロントエンドの経験が少ないので、Gatsbyをカスタマイズするときに最近のReactやそれをコーディングするJSXなどの表現を学べたのはよい経験でした。

またGoのテンプレートエンジンやSCSSについてぼちぼち触っていきたいと思います。