ブログサイトを作りました

こんにちは。amaです。大学生です。プログラミング経験は中学の部活からですが専門にはせず、今では日曜エンジニアをするのが趣味になっています。

昔から技術記事のアウトプットはサボりがちでした。時々Zennは書きましたが、執筆にあたって人に読んでもらうために書いてしまう節があり、億劫になってしまうことがあるんですよね。

しかしながら、「ブログは人のためじゃない、自分の備忘録として書くんだ」という言葉を最近聞きまして、自分のためにもブログサイトを作ろうと思い立って作ることにしました。

技術選定

• Qwik

• Tiptap

• Cloudflare

  • Workers

  • D1

  • R2

私の技術的な趣味として机上のパフォーマンスを追うことがあります。分かりやすいところで言えばRustが大好きです。これを言うと「何でもRustにしたいミーハーだ〜」と思われそうですが……自分は日曜エンジニアなのでロマンを追うことが好きなのです。バイクや車の趣味と同じ！自分にはその趣味がないので分かりません。

フロントエンド

フロントエンドは以前より気になっていたQwikを採用しました。一般に、フロントエンド系のフレームワークではどのようにインタラクティブなコンポーネントを配信するか、ということが問題になります。

• ブラウザ初期表示は基本的に HTML + CSS

• ブラウザ側で変化するコンポーネントはJavaScriptで描画

• JavaScriptをブラウザが実行するまでそのコンポーネントの表示ができない

• 工夫を凝らさないと一部真っ白なページ → 体験が悪くなる

最近よく流行っているNext.jsなどのReact系フレームワークではHydration (水戻し) という手法が使われています。これは、同じコンポーネントをサーバー側とクライアント側で2回描画する方法です。サーバー側でDOM化することによるFCPの短縮、クライアントでの描画結果の置き換えによるシームレスなインタラクティブ化を両立しています。

Qwikはそれらとは異なるResumableというアイデアで実現されています。これはHydrationやRSCの概念をより一般化させたような概念です。Hydrationでは同じコンポーネントを2回パースする計算コスト、配信量もほぼ倍になる転送コストの問題がありますが、それらを回避できる概念です。必要な単位だけパースし、ロードする単位でスクリプトを分割して必要になるまでダウンロードを遅延させます。

Qwikは以前から気にはなっていたのですが、当時はスクリプトを分割する境界を表現するために内部的に特殊なコメント埋め込みなどをしていました。それが気になって見送っていたのですが、久しぶりに触ってみるとv2になってからその挙動が改善され、特殊コメントではない方法で境界宣言を実現したそうなので採用することにしました。

記事の執筆や記事データはTiptapをそのまま使っています。当方元々Neovimユーザーなのですが、マークダウンはWYSIWYG的な執筆ができる方が好みです。我侭なスタイリングにも対応できるようなバックエンドだとTiptapがメジャーなので素直に採用しました。データのシリアライズ形式も分離せずかなりTiptap方式に寄せています。少しロックインされている感もありますが、管理者目線では結構便利なものにはできたと思っています。

インフラ

インフラ系はCloudflareで統一しました。Cloudflareはデプロイも楽ですし、特に難しいことを考えなくてもエッジコンピューティングによる恩恵を得られやすいです。何より安い！このサイトもWorkersの無料プランでデプロイできる範囲に絞り、機能追加していくことが目標です。

実装

デザイン

見た目のとおりです。一風変わったデザインにしてみたいと思っていました。どうせならペーパーライクなデザインにしてみよう！振り切った結果がこれです。

段落のスタイル

昔から両端揃えの組版が大好きでして (Webと相性悪いところですが) …。どうにか両端揃えを違和感なく見せるため色々調べて工夫しました。特に以下の記事は大変参考にさせていただきました。

• きれいな段落。 - lopan.jp

気になる点といえば、レスポンシブに形状が変更されるWeb記事は両端揃えと相性が悪く、両端を無理に合わせにいってしまうと不自然なスペースが空いてしまう可能性はあります。今回は私の趣味を優先しました。

固定ヘッダとツールバー

WYSIWYGエディタを作成するにあたり、キーバインドでサポートしづらい記事要素についてヘッダやツールバーのような要素をStickyに配置したくなります。しかし、Webアプリにおいてツールバーというのは結構厄介な存在なのです。iOSのSafariだとスペースの計算方法に齟齬があるそうで、「ソフトウェアキーボードのすぐ上にツールバーを表示する」ということがうまく行かずに詰まってしまいます。X (旧Twitter) の投稿画面など見てくださったら分かるのですが、ネイティブアプリ版だと下部ツールバーなのにWebアプリだと避けているケースは結構見つかったりします。

幸い、既に調査と参考実装を掲載してくださった方がおりまして、拝借しました。感謝です。

• iOS Safari でキーボード表示時にフッターを固定するもう1つの方法