HonoXでブログを作り直した
タイトルの通り、HonoXでこのブログを作り直しました。
作り直した背景や、技術選定について記載しておこうと思います。
HonoXの使い方などは書いていませんのであしからず。
なぜ作り直したか？
これまでのブログはエンジニアなりたての時にWordPressで作成したものなので、リプレイスしたかったからです。
実は数年前のRemixがリリースされたばかりの頃に、ブログを自分で作ってみたくてRemixで作ったのですが、結局そっちの更新は止めて当初あったWordPressに戻ってしまってました。
一番の理由は、記事管理に使ってたmicroCMSが当時はsyntax-highlightがサポートされてなかったからです。
(今はsyntax-highlightがサポートされているようです。)
オレオレ構文で無理やりsyntax-highlightを効かせるようにしてましたが、書くのもめんどいし、剥がしにくいということでメンテし続けるのがめんどくなって戻ってしまいました。
その後もずっと作り直したいと思ってはいたものの重い腰が上がらなかったのですが、せっかくなので新しい技術の素振りがてら作り直そうと一念発起して今に至ります。
作り"直した"と言っても、元がWordPressなので実質ゼロから作ったのですが。
ブログ名について
インターネット上では「すな」として活動しています。
このブログは日頃調べたことや学んだことをアウトプットする場として使っているので、sandboxのsand部分を活動名に置き換えてsunaboxにしました。
OGイメージもsandboxをイメージして作ったのですが、いまいち砂場感が足りないなという気もしているので今後変更するかもしれません。
技術的な話
ここからは技術周りのことについて記載します。
なぜHonoXにしたか？
当初はNext.jsのapp routerの予定でした。
app routerの諸々の機能のsandbox的な感じで作ろうかと。
ただ、前回Remixで作った時にも思ったのですが、ブログという静的要素が強いコンテンツにおいてapp routerの機能を活かせる場面がそこまであるかと言うと疑問でした。
事前にページ単位でSSGできれば十分なケースがほとんどなので。
それに、app routerは本業でも使っているので、ブログでは別の技術を使うことにしました。
前回の失敗を活かして、できるだけシンプルなものを使いたいと思い、HonoXを選択しています。
Astroもあり得たのですが、昔Cloudflare Workersを使った時の体験がかなり良かったので、HonoXにしました。
使ってみた感想としては、やりたいことがシンプルに実現できてとてもよいです。
そしてやはりdeployまでの速度が速いのが気に入っています。
リリースから半年程度ですが、先人たちが色々と整えてくださってるので設定部分でもほとんど詰まることなく進められました。
MDXの選定
前回はHeadless CMSを使ったのですが、今回はMDXにしようと固く決意しました。
その方がこちら側でハンドリングできる要素が多く、変更に対して柔軟に対応できると思ったからです。
HonoXはviteで動かせて、SSG用のpluginがあるのでそれを使ってbuild時にHTMLを生成するようにしました。
ブログの記事数が多くなってくるとbuildが遅くなるみたいな話も聞くのですが、そこまで大量に記事数があるわけではないので当分は問題にならないだろうと踏んでました。
現在は50記事程度移植したのですが、build時間が2min程度。
耐えられなくはないですが、もっと短くしたいなと思ってます。
OGイメージを毎回SSGで生成しているのを修正したり、buildのキャッシュをうまく使うなど短縮の余地はありそうです。
とは言え、remarkやrehypeなどのpluginがわりと充実してるので、実現したいことは一通りできました。
埋め込みのリンクや、下記のようなハイライトメッセージも実現したくカスタムコンポーネントを作成しています。
あまり独自のカスタムコンポーネントを使うと移行の時などに大変そうな気はしていますが、移行するにしてもMDXから移行はないだろうと思い、よしとしています。
syntax-highlightもpluginに乗っかって実現できたので、総じて良かったです。
スタイリング手法
HonoXはRendererを選べるので、react-rendererを使ってReactを動かすこともできます。
当初はReactのUIライブラリを何かしら使おうと思い、shadcn/uiを導入しました。
一通りSSG含めて動かすところまでできたのですが、せっかく軽量なHonoを使ってるのにReactをimportするのも微妙だなと思い、結局剥がしてdefaultのjsx-rendererを使うことにしました。
なので、最終的にスタイリングはTailwindCSSと一部生のcssを使う形に落ち着いています。
TailwindCSSはちゃんと使ったことなかったので使っておこうくらいのノリです。
CSSを直接書くのはあまり得意ではなかったのですが、AIに聞いたら実現したいことを教えてくれるので、そこまで苦労せずに実現できました。
どうしてもやりたかったのがdarkモード対応です。
darkモード対応自体はすんなりできたのですが、カラーの設定がなかなか難航しました。
radix colorsがユースケースごとにカラースケールが定義されているのでこれを土台にしています。
ユースケースに合わせてスタイリングすると一部微妙になってしまったので、実際にはスケールの一部を抜粋して使用 + 独自定義を織り交ぜる形になりました。
radix colorsはlightモードとdarkモードの差分をCSS側で吸収してくれるように設計されているので、カラースケールの設定をしておけば使う側でdark:のように指定しなくてよくなるのが気に入ってます。
// これだけでlightモードでは黒、darkモードでは白になる
<p class="text-foreground">foo</p>いいね機能をKVで管理
せっかくなのでいいね機能も搭載しました。
いいねの数をどこで管理するかなのですが、せっかくCloudflareを使っているということもあり、Cloudflare Workers KVを使っています。
更新時に最大60秒程度のレイテンシーがあるそうなのですが、厳密に管理したい数でもないので許容としてます。
HonoXはrendererを使ってUIの構築もできるし、単にAPIを作ることもできます。
これを活かして、いいね数を取得するエンドポイントを作ってフロントから叩こうとしたのですが、localではうまくいくもののdeployしてもfunctionが作成されませんでした。
おそらく現段階では@hono/vite-ssgを使用した状態でfunctionを生成する方法がないのかなと思ってますがあまり自信はありません。
時間が空いた時にもうちょっと深堀りしようと思ってますが、違うよとかこうすればできるよとかあれば教えてください。
結局今は別リポジトリでAPIを作って、それを叩く形にしています。
bun
試しにbunを使ってみてます。
普通に動いているし、packageが少ないのもありますが確かに爆速です。
Bun Shellでサクッとスクリプトが書けるのも便利です。
新規ブログ作成時に、frontmatter部分を自動で生成するためのスクリプトを作成したのですがわりと使い勝手がよいです。
biome
こちらも試しにbiomeを使ってみてます。
設定が少なくて済むところはとても楽です。
実は本業でもeslintからの切り替えを検討したのですが、plugin機能がまだ実装されていないこともあって使いたいルールが充足しきれないので断念しています。
このくらいの自分のプロジェクトだったらいいかと思って入れてみました。
入れてみた感想としては、個人的に現時点で使うならeslintかなと思ってます。笑
理由は、lintルールのauto fixが効かないものが多い気がしているからです。
全く効かないわけではなく、一部のルールでは効いているのでルールによるんだろうと思ってます。
後発でこれから成熟していくことを考えると贅沢なのかもしれませんが、これはauto fixできそうだなというものがされないのが個人的にはつらみでした。
個人的にlintに求めるものは、エディタ上でのauto fix >>> 速度なので、auto fix周りの体験が良くなると嬉しいです。
それからbiomeの設定はVS Code上でworkspaceのsettings.jsonに書いてるのですが、なぜかbiomeを使ってないプロジェクトでもエディタ上でbiomeによるエラーが出てしまうのが気になってます。
結局今はbiomeを使ってないプロジェクトで拡張機能をdisabledにするということをして回避してます。
この辺はもしかしたら自分の設定の仕方が悪いだけなのかもしれません。こうすればいいなどありましたら教えてください。
今後やりたいこと
build時間の短縮
せっかく身軽なCloudflare周りのツールを使っているので、build時間をもっと短くしてdeploy周りを軽くしたいです。
アクセシビリティ対応
これまでちゃんとアクセシビリティを学んできてないので、これを機会にちゃんと体系的に学んでこのブログにアウトプット兼ねて反映させていきたいです。
CIでのパフォーマンス計測
SSGでbuildしているし、パフォーマンスが遅くなる部分はさほどないだろうとは思っていますが、CIでパフォーマンス計測できると便利そうなのでどこかで導入しておきたいです。
アクセシビリティ周りのチェックもCIで一緒にできるとよさそう。
まとめ
ようやくブログ作ることができて満足です。
Googleでのindexの対応とかfeedの対応とかも今までしたことなかったので勉強になりました。
HonoXはシンプルで使いやすいです。
いまだにalpha版なので破壊的変更はあるかもしれません。
一方で、リリースから半年程度経っていますが日々開発されているのと、先人たちがissueに対応してくださってるので初期設定で詰まるということはほぼないんじゃないかと思います。
HonoX以外にも試したかった技術を色々と試せて、文字通りsandbox感があって楽しかったです。
ちゃんと月一くらいで更新していきたい所存。
