部誌をHugoからAstro.jsに移行した話
もしかしたらもう気付いている方もいらっしゃるかもしれませんが、今年は部誌を掲載するサイトの制作に使うライブラリを変更しました。
なので今回は、ライブラリを変更した経緯や、それによって何が変わったかについて書いていこうと思います。
(画像はテスト時のスクリーンショット)
HugoとAstro.js
ライブラリを変更した経緯を語るためにはHugoとAstro.jsが何者なのかについて触れる必要があるので、最初に軽く紹介します。
Hugo
Hugoは、GitBookというブログに特化したライブラリのフォークです。
特徴としては、先代のGitBookと同じく簡単にブログのようなサイトを制作することができるという点が挙げられます。
The world’s fastest framework for building websites
The world’s fastest framework for building websites
gohugo.io
Astro.js
Astro.jsは、比較的最近登場したライブラリです。
特徴は、簡単にコンポーネントを扱うことができたり、様々なフレームワークに対応していたり、ちょっと引くほど最適化をしてくれるおかげで阿部寛のHP並みの速度を簡単に手に入れることができるという点です。
Astro
Astro builds fast content sites, powerful web applications, dynamic server APIs, and everything in-between.
astro.build
移行した要因
もはや先ほどの説明で全てを話した気がしますが、一応順序立てて説明します。
1.速度
先ほども紹介したように、Astro.jsは信じられないレベルで速いです。
Hugoの場合は最適化が弱いので、各コンポーネントで外部ファイルを読み込むと、それに応じて最終的なページにおける読み込み時間が増加します。
画像は去年の部誌のサイトのものですが、非常に多くのファイルが読み込まれていることが分かります。
Astro.jsの場合、スクリプトやスタイルを1つのファイルに出来るだけ同梱するので、ファイルの読み込みが格段に減少し、サイトを全体的に高速化することができます。
2.拡張性
HugoやAstro.jsにはそれぞれShort Code、コンポーネントという「特定の部品を切り分け、再利用できるようにする」ことを目的とした仕組みがあります。
ただ、HugoのShort Codeは
{{< link-card "https://www.example.com">}}
といった風に、JavaScriptにもHTMLにも似つかわしくない記法で利用する必要があり、少々独特なものとなっています。
一方、Astro.jsのコンポーネントは、
<link-card href="https://www.example.com" />
という風に、HTMLと同じように利用することができます。(いわゆるJSXというもの)
したがって、部品の共通化という観点から見てもAstro.jsに軍配が上がります。
以上の理由から、部誌をAstro.jsへ移行することに決めました。
良かったこと、悪かったこと
部誌をAstro.jsへ移行して、速度が上がったり、以前よりも格段にスタイルの適用が簡単になりました。
ただ、これほど便利なAstro.jsにも問題点はあります。
1.モジュール化されていないライブラリが使いにくい
1つ目は、モジュール化されていないライブラリが使いにくいという点です。
Astro.jsではモジュール化されたライブラリはimportすれば使えますが、モジュール化されていないものはimportに対応しておらず、少し面倒なことになります。
まあ最悪is:inlineでゴリ押したら使えるっちゃ使えますが、その場合は最適化の恩恵を受けられないので微妙です。
もしいい感じの解決策を知っている方がいらっしゃるならぜひ教えてください。
2.テンプレートが少ない
2つ目は、Hugoに比べるとテンプレートの種類が少ないという点です。
まあこちらも全部自分で作ればなんとかなりますが、やはりテンプレートを使って楽をしたいものです。
というかそもそもHugoのテンプレートが多すぎるだけな気が…
まとめ
今回はHugoとAstro.jsを比較しつつAstro.jsへ移行した理由について話しました。
まだAstro.jsにもいくつかの問題がありますが、なんにせよ使いやすいので、機会があればぜひ試してみてほしいです。