ハクソク

世界を動かす技術を、日本語で。

Jeffgeerling.comがHugoに移行しました

141日前原文(jeffgeerling.com)

概要

  • Drupal から Hugo への移行理由と経緯
  • 静的サイトジェネレーター（ SSG）の選定理由
  • Markdown 中心の執筆ワークフローの利便性
  • 大規模CMSのメンテナンス負担と課題
  • 今後の課題（コメント機能・検索機能）

DrupalからHugoへの移行経緯

  • 2009年から Drupal を使用、バージョン6から10まで段階的にアップグレード
  • 本業でも同じCMSを使い続けていたため、サイトでの「 dogfooding」を実施
  • Drupal 7から8への移行が特に大変で、個人ブログに エンタープライズ向けDXP を維持するモチベーション低下
  • ブログは趣味・メモ・YouTube動画の補足用であり、複雑なCMS管理に時間を割きたくない現状

静的サイトジェネレーター（SSG）の選定理由

  • 他の趣味サイトでは 静的ホスティング を活用
    • 更新停止サイトはスクレイピングしてアーカイブ化
    • 継続運用したいサイトは Jekyll や Hugo へ移行
  • Jekyllは GitHub Pages での無料ホスティングに最適
  • Ruby非習得のため、 Hugo を自前インフラ向けに選択（Geerling Engineering等）
  • Hugoはセットアップが簡単で高速

サイト移行と運用課題

  • GitHub issueで移行作業を進行中
  • 画像参照ミスや古いURLの消失リスク
  • 20年分・3500件超の投稿データ移行の困難
  • 可能な限り既存URL維持やリダイレクト追加を試みるが、完全な移行は困難

Markdown中心のワークフロー

  • 2020年以降、全投稿を Markdown で執筆

  • それ以前も Sublime Text でMarkdown下書き→HTML化して投稿

  • HugoはMarkdownを ネイティブサポート しており、執筆体験が向上

  • Drupal 6時代は30個以上のモジュールを導入したが、アップグレードのたびに問題発生

  • Drupal 8以降は機能を最小限に絞った結果、コンテンツ作成体験が悪化

    • Markdownファイルで記事作成
    • Drupalで新規記事作成・Markdown貼り付け・タイトル追加
    • 画像を個別アップロードし、本文内に1枚ずつ挿入
    • 投稿日時フィールドを手動で調整
    • 公開設定を切り替えて保存
    • AnsibleでDrupal/Nginx/Cloudflareキャッシュを手動パージ
    • これらの作業が執筆や創造性に寄与せず、単なる手間

  • Drupalには自動化モジュールも存在するが、モジュールの安定化・パッチ管理に疲弊

  • メジャーバージョンアップごとに WYSIWYGエディタ・メディア管理・コンテンツフィールド 等の再構築が必要だった過去

Hugo運用のシンプルさ

  • 元々Markdownで執筆しているため、Hugoでは 1ステップ で公開可能
  • 投稿のfrontmatterで日付・ドラフト設定を変更するだけ
  • コマンド一発（hugo && git commit -m "Updated post." && git push）で即時公開
  • Composer・Drush・PHP・MariaDB・Nginx・Cloudflare 等の複雑な管理から解放
  • 複数ユーザー・RBAC等が必要な大規模サイトならDrupalも有効だが、個人ブログには不向き

今後の課題（TODOs）

  • 当面は コメント機能 が全サイトで未実装（後日、自前静的コメントシステム導入予定）
  • コメント欄はモデレーション負担があるものの、ブログの一体感に不可欠
  • サイト内検索 機能も未実装、過去はApache Solrと連携していたが現在は未導入
  • Hugoでの検索機能実装方法を検討中

Hackerたちの意見

ずいぶん前に、管理サービスのsvbtleからHugoに移行したんだけど、正直言って後悔してる。市販のテーマを使うことにしたんだけど、あまりニーズに合わなくて、結局フォークしちゃった。Hugoはユーザーランドが結構壊れることが多いし、私の持ってる複雑なテーマはメンテナンスがめっちゃ大変。ほんとに、めっちゃね。今は修正するための時間を正当化できなくて、投稿も全然してない。サイトすらコンパイルできないし。理論的には古いバージョンのHugoを使うこともできるけど、いつ壊れたのか全然わからないから、どこまで遡ればいいのかもわからない。だから、アドバイスとしては、サイトを生成するのに使ったバイナリをソース管理に提出しておくこと。gitはバイナリファイルにはあんまり向いてないけど、いつか感謝されると思うよ。

└

CI設定でバージョンを指定するのはどう？ [0] あと、動作するバージョンをバイナリサーチで探せること知ってる？ 0.154.0、0.77.0、0.115.0…（自分も一度やったことある） [0]: https://github.com/oslc-op/website/blob/9b63c72dbb28c2d3733c...

└

徐々に気づいてきたんだけど、更新しなくてもいいソフトウェアってあるよね。静的サイトジェネレーターは、入力をコントロールして、出力が静的ファイルの塊なら、セキュリティの問題はほぼないと思う。新しいバージョンに必要な機能が含まれてない限り、古いバージョンを永遠に使っても全然大丈夫。サイトがビルドするSSGのバージョンをメモしておくか（ソース管理にコミットしてもいいし）、そのまま人生を進めればいいんだ。OSやCPUアーキテクチャがあまり変わらなければ動くし（最悪の場合、必要な条件をエミュレートする技術はあると思うし）、すでに「完成」してるソフトウェアもあるから、更新する必要はないんだよね。

└

理論的には古いバージョンのHugoを使うこともできるけど、いつ壊れたのか全然わからないから、どこまで遡ればいいのかもわからない。 同じ問題を抱えてた。バイナリサーチが最近のトリックだね。SSGの場合、すべてがうまくいってるならアップグレードする意味はあまりないし、計画的な移行がこの場合はいいと思う。HugoのバージョンをHTMLコメントに印刷して、gitで追跡することもできるよ。

└

最近、Hugoのブログテーマを更新したら壊れちゃって、全く新しいテーマに移行しなきゃいけなかったんだ。めっちゃ面倒だった。これからは多分、更新しないと思う。

└

市販のバイナリを使うなら、${project}/bin/にそのバイナリを置いて、.gitignoreに追加して、README.mdやインストールスクリプトにダウンロードURLを記載して、プロジェクト全体のSHA256SUMSファイル（またはB3SUMSなど）にチェックサムをコミットすればいいよ。Git LFSのローファイ版みたいな感じ。

└

AIが管理するカスタムサイトジェネレーターに移行したんだけど、これが自分の使い方にはぴったり。全てを完全にコントロールできるし、何も壊れないから安心。

└

私も似たような問題があったけど、Jekyllでね。カスタマイズしたテーマがあって、途中のアップデートで全てが壊れちゃった。だから、静的サイトジェネレーターを更新する必要がないっていう兄弟コメントにはすごく同意するよ。これはHugoだけの話じゃないしね。残念ながら、私のサイトはGitHubでホスティングされてたから、アップデートに関しては本当に選択肢がなかったんだ。（ピン留めが助けになったかは分からないけど。）

└

これ、何回か痛い目にあったから、今はHugoのバイナリをソース管理してる。壊れないバージョンを見つけるために、リリースをちょっと掘り下げる必要があったよ。

└

だから、アドバイスとしては、サイトを生成するのに使ったバイナリをソース管理に提出しておくことだね。gitはバイナリファイルに最適じゃないけど、いつか感謝することになると思うよ。全バイナリは必要ないから、go run github.com/gohugoio/hugo@vX.Y.Z "$@"をhugo.shみたいなスクリプトに入れてソース管理に置いて、それをHugoのバイナリの代わりに実行すればいい。Goをインストールする必要があるけど、すごく後方互換性があるから、新しいGoバージョンにアップデートしても古いHugoバージョンが壊れることはまずないよ。

└

同じ問題があって、今はHugoのテーマシステムと戦うより、自分が必要な機能を持った静的サイトジェネレーターをVibe Engineerで作った方が簡単かなって考えてる。サイトに必要なものは結構シンプルだから、正直言ってカスタムビルドの方がいいかもしれない。もし壊れたら、鏡を見て犯人を探せばいいしね =)

面白いね。今、HugoからZolaに移行しようとしてるんだ。個人的には、Zolaの設定やテンプレートオプションの方がHugoより理解しやすい気がする。

└

要件はあまりないけど、ZolaとGistが好きなんだ。ちゃんと動くし、何も気にしなくていいから。

└

Hugoがあまり好きじゃなくて、サイトをJekyllからZolaに移したんだけど、全然後悔してないよ。ZolaのGitHub Actionsを使ってテストやビルド、GitHub Pagesにデプロイもしてる。

数年前に、自分で書いたCommon Lisp（CL）ベースの静的サイトジェネレーターに個人サイトを移行することにしたんだ。振り返ってみると、これが自分のサイトにとって最高の決断の一つだった。最初は850行くらいのコードだったけど、徐々に1500行くらいに増えた。ブログ記事や任意のページ、ゲストブック、コメントページ、タグ一覧、タグごとのRSSフィード、統合RSSフィード、ディレクトリ一覧ページなどを静的にレンダリングすることができる。自分のサイトのこの小さな「機械」を維持するのが本当に楽しい。コードの一行一行を理解しているのが一番の魅力。HTMLやCSSも含めて、全て手作りなんだ。これには二つの利点がある。サイトを構成する全てのバイトに美的感覚を保つ手助けになるし、新しい機能やセクションを追加するのもすごく早い。ジェネレーターはレイヤー化された再利用可能な関数のセットとして作ったから、大体の新機能は既存の関数を呼び出す小さな高レベルの関数を書くことに収束する。例えば、先月は自分の投稿にリンクしている他のページをリストする「バックリンク」ページを追加したいと思ったんだけど、新しいCLコードは約40行で、実装から公開まで15分もかからなかった。この小さな趣味プロジェクトは年々安定してきて、あまり手を加える必要もなくなった。ほとんど邪魔にならず、執筆に集中できるのが一番大事だと思う。

└

奥さんのPythonバージョン、すごいね。複雑なテンプレートエンジンを使う代わりに、狭いユースケースにターゲットを絞った単純な文字列置換をするって発想は思いつかなかったよ。

└

投稿はすごく読みやすそうだね。ランディングページに投稿のリンクを全部載せてるけど、もし1000件や2000件の投稿があったらどうするの？ページネーションを考えたことある？

└

自分も同じことをしたけど、サイトジェネレーターをGoで実装したよ。サイトは年々大きくなってるけど、MDファイル、HTMLスニペット、静的ファイルから1秒以内でゼロからビルドできる！RSSフィードジェネレーターもあって、ほとんどのプログラミング言語でコードをハイライトできるのが重要なんだ。いろんな言語で投稿を書くからね。自分のを実装する前にHugoも試したけど、いくつかの機能はHugoから取り入れたけど、Hugoは自分が求めていたものに対して過剰に設計されているように見えた（基本的には、マークダウンをメイン言語にして、他のファイルから生のHTMLやマークダウンを含めることができる簡単なテンプレート機能で、各ファイルはテンプレート言語で使える変数を定義できる）。式言語のためにGoの組み込みパーサーを使ったから、実装がすごく簡単だった！コードの構文ハイライトにはこれを使った：https://github.com/alecthomas/chroma マークダウンにはこれを使った：https://github.com/russross/blackfriday あとは、シンプルで読みやすいGoコードで自分で実装したよ。

└

自分で書いたCommon Lispベースの静的サイトジェネレーターにウェブサイトを移行することにしたよ。多くのプログラマーがブログを始めるときの最初の衝動は、自分のブログエンジンを書くことなんだ。そういう特定の穴にハマらず、実際にそのエンジンを使ってるのは素晴らしいね。 [0] 移行したって言ってたから、すでにブログを書く習慣があったってことだよね。でも、それでも、

└

「静的ブログ」でコメントはどうやって処理してるの？

└

自分の「Go 101」本のサイトと似てて、Goコードが約1000行（9年前は500行から始めた）。サイト全体を1つのGoバイナリにまとめられるよ。

└

ブログジェネレーターを書くのは楽しいだけじゃなくて、静的な構文ハイライトや数式レンダリング、カスタムビルドステップなど、究極のコントロールを与えてくれる。めっちゃおすすめ！

└

シングルパーパスの静的サイトジェネレーターの自由さと安定感には満足してるよ。前のプロジェクト、Tclssgは最初から公開されてて再利用可能だったんだ。これには大きな利点があって、ユーザーと一緒に作業することを学べたし、自分では実装しなかった機能も強制的に実装することになった。実際、ドキュメントも書いたし、他の人が使ってるのを見るのが一番の楽しみだった。でも、その分できることに制約もあった。デフォルトのテンプレートのレンダリング方法を簡単に捨てたり、大きく変えたりすることはできなかったからね。自分のサイト専用のSSGなら、そういうことができる。もし複数の大きなサイトを管理したり、多くのコラボレーターと一緒に作業してたら、標準的なものに頼るか、自分のSSGを抽出して公開してたと思う。個人サイトなら、カスタムの方がいいことが多いと思うよ。今のジェネレーターは、Pythonが約900行、Pandoc Luaが700行くらい。安定性に対する最大の脅威は、自分のリライトや実験、例えばClojureからPythonに移行したことだった。歴史は自分のサイトに記録してあるよ：https://dbohdan.com/about#technical-history

└

自己ホストのブログや私みたいな性格の人にとっての唯一の問題は、実際にブログを書くよりもブログエンジンをいじる時間が多くなっちゃうことだよ。結局、ホスティングされたソリューションに戻ることになったのは、そういうコントロールを許さないからで、できることはサイトをいじるのではなく、ただ書くことだけになったんだ。

└

emacsとorgベースのソリューションでブログを始めたんだけど、最悪だった。サイトのイメージはあったけど、orgエクスポーターがデフォルトのスタイルを押し付けてきた。デフォルトのorg-htmlエクスポーターが追加する余計なものを取り除くのに、ブログエンジンをゼロから作るよりも時間がかかっちゃった。カスタムエクスポートテンプレートを設定する方法もあるけど、ドキュメントからはわからなかった。emacs/orgのドキュメントは、emacsの内部を理解していない人にはひどく書かれてると思うし、ブログを書くためだけにemacsの内部をマスターする時間をかける気にはなれなかった。だから、しばらくは中途半端なorg->pandoc->htmlの解決策でやってたけど、今はJekyllにして、ブログ体験がすごく良くなったよ。

これ、馬鹿げてると思うし、これに関しては譲れないね。昨日コメントに書いたんだけど、ジェフが彼の投稿で完全に確認してくれた：SSGはインタラクティブ性やフィードバックがない静的サイトには良い。もしインタラクティブ性やフィードバックが必要なら、誰か（自分か第三者のサービスプロバイダー）がサーバーを運営しなきゃならない。どうせサーバーを運営するなら、マークダウンから動的に生成されたコンテンツを提供するのは簡単そうだし、SSGパイプラインが追加するのは依存関係や壊れる要素だけだと思う。静的サイトで運営されている大きなオタクブログもいくつかあるけど、全体のスタックや行われている作業の頻度、依存している外部サービスの数を考えると、最初からカスタムバックエンドを自分で書いていた方が、いろんな指標で良かったと思う。ジェフ：これを後悔すると思うよ。コメントのような基本的なインタラクティブ性を無理やり組み込もうとして、5〜10年無駄にすることになると思う。SSGに移行する前にDrupalやJoomlaも使って管理してたけど、最終的に感じていた痛みのための合理的な中間点があることに気づいた：マークダウンを動的にコンパイルするシンプルなサーバーを書く/運営することだよ。良い古きSSRだね。Drupalよりもずっと軽くて安くて簡単だし、サーバーが必要な全ての柔軟性や機能を保持できる。『自己ホスティングの技術は難しすぎたから、第三者サービスを使わざるを得ない楽な道を選んだ』って選択肢には屈しないで。個人サイトをSSG化するのは、完全に第三者サービスに任せる第一歩だと思う。

└

サーバーを運営しているなら、マークダウンから動的に生成されたコンテンツを提供するのは些細なことに思えるよね。訪問者が十分に増えたり、悪意のあるAIボットがサイトをスクレイピングしてクラッシュするまでは、またはオートスケーリングのプロバイダーを使っていて実際にお金がかかるようになるまではね。問題はマークダウンからHTMLへの変換（これはかなり速い）じゃなくて、もっと多くの機能を追加する第一歩になることなんだ。気づいたら、サーバーサイドのNode.jsデーモンが必要なNext.jsのブログを運営していて、テーマの切り替えがStack Overflowからコピペしたものになってる。ブログの場合、閲覧数とコメントやその他のサーバーを必要とするアクションの比率は、たぶん100:1か1000:1くらいだし、ページの読み込みがボットやスクレイパーによるものならもっとだよ。 > 自分のサイトをSSGにするのは、完全にサードパーティのサービスに移行する第一歩だと思う。なんでかって？インタラクティブな部分やフィードバックは、DrupalやJoomla、WordPress、Django、その他のものを運営するのと同じサイトで動かせる10行のスクリプトでもできるから。ジェフはまさにそれをやろうとしてるみたいだね。

└

自分のクッキーレス分析を自己ホスティングしてるし、前はDrupal（LEMPスタック）とApache Solrを別々のサーバーでホスティングしてたんだ。自己ホスティングには慣れてるし、使うコメントソリューションも自己ホスティングするつもりだよ。SSGと1、2個の小さな自己ホスティングのOSSツールを使う場合のコードの面積は、Drupalや他のCMSを運営していた頃よりもずっと小さいんだ。

└

SSGはインタラクティブ性やフィードバックがない静的サイトには向いてるよ。もしインタラクティブ性やフィードバックが必要なら、誰か（自分かサードパーティのサービスプロバイダー）がサーバーを運営しなきゃならない。私のウェブサイトでは両方やってるよ。静的HTMLページは静的サイトジェネレーターで生成してるし、コメントはCommon LispとHunchentootを使って自分で書いたサーバーサイドプログラムで受け付けてるんだ。

└

コメントみたいな基本的なインタラクティビティを無理やり入れる？ [https://gohugo.io/content-management/comments/] ここにはオープンソースのコメントシステムの巨大なリストが含まれてる。なんでみんな静的サイトジェネレーターが自分のものを作るのに良い候補だって言うのか全然理解できない。人気で安定した選択肢がたくさんあるのに。Hugoについて嫌なのは、他の人のテーマを使う体験なんだよね。

└

でも、Disqusはどうなの？それともGitHub Issuesからコメントを表示するやつ？

└

サイトをSSGに変えたけど、全然後悔してない。やっぱり、インタラクティブ性が少ない方がいいと思う。

└

SSGパイプラインが追加するのは、依存関係や壊れるものだけ。これは静的サイト生成の正反対だね。

└

ここでAstroが本当に光ると思う。多くの人が「インタラクティビティの島」ってコンセプトで手を伸ばしたけど、個人的には必要なときにサーバーAPIを使ってほぼ静的なサイトを簡単に構築できるのが killer featureだと思う。複数のAstroサイトを管理してるけど、結局どれも少なくともいくつかの小さなサーバーエンドポイントが必要になった。Astroを使えば、それをすごく簡単にできて、静的な部分のメンテナンスが面倒にならないんだ。

└

大学の頃にブログエンジンを書き始めたんだ。それ以来ずっと取り組んでて、クールなウェブ機能を実装したり遊んだりできた。10年以上前にMarkdownを実装したけど、後悔はしてないよ。Markdownは保存時に一度HTMLに変換されるし、ほぼ最初からRSSもサポートしてる。RSSは後にバックアップと復元システムの基盤にもなった。数年前にはSSG機能も実装したよ（HTML、CSS、画像などをZIPにエクスポート）。https://github.com/theandrewbailey/gram

└

そうだね、SSGは片道通行みたいなもんだ。一度入ったら、ウェブサイトをもっとダイナミックにするのはすごく難しい。でも、ウェブサイトを作るのが好きな人もいるし、それで満足してる人もいるよね。それに、別のブログ投稿を書くこともできるしね :)

昨年ブログを立ち上げたときにHugoを使ったんだけど、合計18件の投稿をした。多分、そのうちの3/4はHugoの問題で公開しようとしたときにトラブルがあった。すごくイライラしたよ。

└

最近、HugoからDIYのPython静的サイトジェネレーターに移行したんだ。困ったのは、Hugoのやり方を学ぶのがもどかしくて、すでに慣れてる言語でさっとコードが書けるのにって思ったことだね。

最近のPelicanの温度はどう？ [https://getpelican.com] 私の見たところ、最高のPython SSGはHugoとPelicanにほぼ絞られてる。SSGはずっと好きだけど、ActivityPubの統合もRSSの広範な採用がない中ではとても魅力的に見えるね。

└

Happy Pelicanユーザーです。Pythonがわかるなら、これがベストだよ。

└

Pelicanを使ってるけど、すごくうまくいってる。前はNikolaを使ってたけど、2つの理由でやめたんだ。一つは、あらゆる機能を追加しようとして、依存関係がどんどん増えて怖くなったこと。もう一つは、使いにくかったこと。例えば、YouTubeの動画を埋め込むのに、ドキュメントやプラグイン、いろんな新しい構文を調べるのが大変だった。で、一番の問題は、すべてのSSGに影響することだけど、デフォルトでインクリメンタルビルドをしようとすること。特に当時のNikolaはそれがひどかった。設定ファイルやテーマ、テンプレートの変更が重要だって気づかず、ソースファイルと出力ファイルのタイムスタンプについても曖昧だった。これで、クリンビルドとインクリメンタルビルドで出力が違うという大罪を犯してしまった。Pelicanはシンプルさを保ってるね。

└

Pelicanが今でも人気かどうかわからないけど、数年使ってるよ。結構いい感じだよ！めっちゃおすすめ！唯一の欠点は、プロジェクトサイトのドキュメントがすごくよくできてるんだけど、90%くらいで止まっちゃってる感じ。高レベルのことはしっかり書いてあるけど、最後の10%の細かいところが抜けてるんだよね。まあ、僕がPythonをちょっとしか使わないから、そう感じるだけかもしれないけど。ちなみに、プロジェクトのメンテナンスをしてる人がいたら、僕の意見を気にしないでね。プロジェクトのメンテナンスにはすごく感謝してるし（だって、今でもPelican使ってるから！）。ドキュメントに対する気持ちを除けば、Pelicanであまりカスタマイズしないなら、すごくいいSSGだよ。

└

Pelicanを使ってて、自作のプラグインもいくつかあるけど、すごくうまく動いてるよ。毎月いくつかのコミットがあるから、死んだプロジェクトじゃないね。

もしすでにMarkdownで投稿を書いてるなら、確かに意味あるよね。約1年前に500以上の投稿があるJekyllブログをHugoに移行したけど、全体的にはプラスになったかな。ただ、ドキュメントで構文を調べることが多かったのは確か。最近はあまりないけど、テンプレートの構文を理解するのは大変だった。Jeff、ドラフトをfalseに設定する必要はないよ。ドラフトを別のディレクトリに分けて、Hugoのカスケード機能を使えばいい。あと、ファイル名をYYYY-MM-DDで始めれば、フロントマターの日付を更新する必要もないよ。ちょっと注意だけど、投稿には触れてなかったけど、HugoはきれいなURLのために末尾にスラッシュを追加するからね。前からあったかは分からないけど、調整しないと新しい挙動や正規URLの違いが出るかも。JekyllからHugoに切り替えたとき、詳細を含めた1万字の投稿を書いたし、Pythonやシェルスクリプトを使って投稿の変換を自動化した方法もカバーしたよ。上記のことに焦点を当てたセクションもあるから、見てみて：https://nickjanetakis.com/blog/converting-my-500-page-blog-f...

└

約1年前に、500以上の投稿があるJekyllブログをHugoに移行したんだ。なんでかって？Jekyllを使ってて満足してたのに、何か見落としてるのかな？

ここ3年間Hugoを使ってるけど、一番の教訓は使ってるテーマをフォークして、サブモジュールは使わないことだね。テーマを最新に保つのに急ぐ必要はないし、フォークしたらテーマを完全にコントロールできる。Hugoの新しいバージョンに更新する時に、たまに壊れることはあったけど、テーマのいくつかの部分を変更するのもそんなに時間はかからなかった。コメントがどう実装されるのか気になるけど、SSGに追加するのは簡単じゃなさそうだね。

└

これ。テーマはサイトごとに個別だからね。Drupalのテーマを直接移行しようとしたけど、ビューのスタイルクラスが多すぎて諦めたよ（笑）。いくつかのガイドではサブモジュールを追加するように言ってるけど、私は直接インクルードして、レイアウトをオーバーライドするのが好きだな。

ずっと前に、個人サイト用にすごくシンプルな静的サイトジェネレーターを作ったんだ。主にGitHubやCloudflareページを使って個人サイトをホストするために遊びたかったから。数ヶ月前には、大きなSSGツールを比較し始めたんだけど、もう少ししっかりしたものが欲しくて…たくさん実験した結果、当時は11tyに落ち着いたんだけど、Liquidテンプレートを書くのが本当に楽しめなかったし、Liquidを使って再利用可能なコンポーネントを書くのもすごく不器用に感じた。11tyでJSXベースのテンプレートを使うのがもっと簡単だったらいいのにと思ってるけど、どのステップも「正しい」やり方に逆らってる気がする。だからクリスマス休暇中にNextJS SSGで遊んでみたけど、基本的には自分が欲しいものは全部できるんだけど（いくつか複雑な注意点があるけど）、ドリルで十分なところを油田掘削機を使おうとしてる気がしてならない… 11tyとNextJSの間にある何かのおすすめがあれば教えてほしいな。11tyに似た構造で、SSGを使ってJSXを使って、最終的にクライアントサイドのコンポーネントにハイドレートされるものが欲しい。もう一つ試してみたいのは、Tempest [1]の上に何かカスタムのものを作って、静的ページ生成の重い作業をほとんどやってもらうことだけど、もちろんそれはクライアントサイドのコンポーネントには全く役立たないよね。[1]: https://tempestphp.com

└

スタートアップのマーケティングサイトとブログをNextJSからAstroに移したんだけど、満足してるよ。主に静的サイトに焦点を当てつつ、必要に応じてバックエンドロジックも書ける中間的な存在だね。静的コンテンツを本当に静的（キャッシュ可能）として扱うのが難しかったし、シンプルな使い方にしてはすごく複雑に感じた。

└

たくさん実験した結果、当時は11tyに落ち着いたんだけど、Liquidテンプレートを書くのが本当に苦手で、Liquidを使って再利用可能なコンポーネントを書くのはすごく不器用に感じた。11tyでJSXベースのテンプレートを使うのがもっと簡単だったらいいのに、って思うけど、どのステップも「正しい」やり方に逆らってる気がする。Eleventyって、一般的な古いスタイルのテンプレート言語のほとんどをサポートしてないの？一度、Mustacheを使ってPunchからEleventyにサイトを移行したことがあるよ。Eleventyは素晴らしいし、ビルド時間が問題じゃなければHugoよりも好きかも。少なくとも、ここに書いてあるようにテンプレートが壊れることはないしね。結局、サイトを一から作り直したよ（v0の頃にちょっとしたvibecodingマジックで始めた）Astroでね。[1] https://github.com/laktek/punch

特定の静的サイトジェネレーターを選ぶ決定プロセスについて、もっと理由を知りたいな。たくさんの選択肢があって、「大手」と呼べるものもいくつかあるから、移行を考えてる人は同じプロセスを経ると思う。つまり、Hugo、Eleventy（11ty）、Jekyllなどが有名だよね。Jeffの決定プロセスを見るのは面白そう。Hugoはすごく確立されてるけど、同時に壊れる変更をあまり気にしないことで知られてる。そんな年数のプロジェクトは、素晴らしいユーザーベースを尊重して、入力/出力の互換性をしっかり保証すべきだと思う。安定性に関してまだ足りないと自称する0.x症候群に悩まされるべきじゃないけど、まあ、Hugoはその点であまり良くないね。テーマやうまく機能する入力がアップデートで壊れることがあって、これはうちにとって大きな欠点だよ。

└

特に、Hugoはv0.146でテンプレートシステムを全面的に見直したせいで、アップグレードしたらブログがビルド失敗しちゃったんだよね。今日の時点で、ドキュメントもまだ新しいシステムに合わせて完全には調整されてないみたい。

「v0.146.0でHugoのテンプレートシステムを完全に見直しました。関連するドキュメントを最新にする作業を進めていますが、それまでの間はこのページを参照してください。」 壊れる変更は気にしないけど、ドキュメントがその変更を反映してくれたらいいのにな。