このブログの使用技術

Good な点

ほぼ設定ファイルを書いてない。

Denoを使ってるし、SSRのためブラウザコードへのトランスパイルを考えないので package.json, webpack.config とか vite.config とか難しいことは何もいらない。

Deno Deployでホスティングしてるので、ホスティングのための設定ファイルも必要なくgitにpushしたら server.ts を実行するだけ。

ブログ作成のため使用したSSG(Static Site Generator)の遍歴

- Wordpress
- Hugo (Golang)
- Gatsby.js
- Next.js
- Docusaulus
- Sapper.js
- Aleph.js

フロントエンドの勉強も兼ねて色々と触ってきたけど、プロジェクト内にファイルが散らかるの面倒臭い...

JAMスタックだと自分で好みのページレイアウトに書き換えたりもできるのだけど、趣味の個人ブログだとあんまり必要ないなって気づいた。
（仕事の商用サイトは気合い入れて作ったほうがいいので、Reactやその他のライブラリを使ったほうがいいのだろうけど）

結局の所はファイルベースのルーティング&SSGと Prism.js のコードハイライトがあれば何でもいいな...という感じなのでDiplodocus はかなりハマってる

このサイトは Deno Deploy でホスティングしている。
Serverless Function (Edge computing) による SSR ということ。

一般的な Object Storage + CDN という一般的なサイト配信に対して、SSRの計算コスト分レスポンスが遅くなるのではないかと思ったが、

Light House はかなり良い
(まだページコンテンツが少ないからかもしれないけど)

Qiita とか Zenn みたいな記事投稿サービスは動的なコンテンツをPOSTして永続化するためバックエンドにDBとかが必要だが、個人ブログ程度なら更新頻度も少ないので更新のたび git に push > deploy する SSG がベストだと言う認識だった...

のだが、ムーアの法則でCPUなどもどんどん高速化してるので、ボトルネックは計算リソースよりネットワークの速度とか物理的な距離とかに移ってきているのかもしれない。Deno Deploy はエッジでTypeScriptを実行するので、クライアントとネットワーク距離が近いので早いってこと。

今の所いい感じだが、アクセスが増えるとキャッシュの影響とかでSSGに劣るかも知れないし、同じエッジでのSSRでも Remix.js のほうが効率的になったりするのかもしれないが、アクセスが増えてきたら考えればいい。

(今の所、Deno Deploy は無料で使えてるし)