どうして作ったか
自身のウェブサイトを作りたいと前々から思っていて、 苦手なフロントエンドを克服することを目標に当ウェブサイトを開発・運営しています。
ホスティング・技術選定
経験としてはNuxtとGitHub Pagesを少しだけ触ったことがあります。
今回は界隈の情勢や将来性も含めNext.jsとVercelでウェブサイトを作るつもりでした。
しかし、AstroとCloudflare Pagesを知り、
それらでウェブサイトを作ることにしました。
(一応、74のウェブサイトは
Next.jsとGitHub Pagesで開発されていますが、
当ウェブサイトよりは開発が活発ではありません。)
メタフレームワーク（フロントエンドフレームワーク） では、
Next.jsやNuxt、SvelteKit、Remixなどが挙げられ、
SSGではGatsbyやHugoなどが挙げられますが、
カスタマイズ性とパフォーマンスの点においては、Astroはずば抜けています。
静的ホスティングはNetlifyやVercelが挙げられますが、 無料プランにおいてはCloudflare Pagesが抜きん出ているでしょうか。
選定の基準としては、
パフォーマンス（ネットワークの速度） >= メンテナンスの状態 >= 使いやすさの順で評価しています。
Astro
全ては説明しきれませんが、いくつかAstroの素晴らしい点をご紹介します。
インテグレーション
package.jsonに追加されるので、Astro専用のパッケージという立ち位置です。
ReactやVueなどのJSライブラリや、
TailwindCSSなどのCSSフレームワークに加えて、
SSRアダプターや便利なインテグレーションが多くあります。
pnpm astro add react
pnpm astro add react tailwind partytown
１コマンドでインストールから設定まで自動で行ってくれます。
pnpm dlx @astrojs/upgrade
１コマンドでアップグレード（アップデート）も一括で行ってくれます。
高速
パフォーマンスを重視して開発されているので、 JavaScriptのコードが全てHTMLとCSSに変換されるので、 （出来上がった形としてクライアントに送信される）とにかく速いです。 しかし、そんなことをすれば動的なコンテンツは動かなくなります。 その対応策としてクライアントディレクティブがあります。 これを使えば一部（コンポーネント）のみがJavaScriptで制御されることになります。
この一部がAstroコンポーネントになるわけですが、 ReactやVueなどで作ったコンポーネントも呼び出せ、これらのUIフレームワークを混合的に使えます。 もちろん、完全に静的なコンポーネントを作ることも可能で、その場合は通常通り変換が行われます。
この高速化に複雑な設定は必要ありません。
もっと多くのことをしようとすれば複雑にはなりますが、これについても言及されています。
単純なJSXのみで記述することも出来るし（UIフレームワークなしで）、
必要ならば、より踏み込んだ機能（新しい機能やAPI、UIフレームワークなど）にも手を出せる。
ドキュメント
公式ドキュメントが日本語に対応しています。 日本語化が進んでいない部分がありますが、基本的な機能や技術については書かれています。 チュートリアルはブログの作成が日本語化されています。
日本語の記事もそれなりに書かれていますが、技術に偏りがあるのは事実です。
より多くのことをしたいなら、英語の記事を読む必要はあります。
所感
特定のJSライブラリに依存しないので、移行について考える必要が少なくなりますし、 技術や仕様的に不可能だったことが出来るようになる可能性もあります。
学習コストは低いですが、ドキュメントの一部は英語であったり、 新しい機能について日本語の記事はもちろん、英語の記事もほとんどないことがあります。
高速化は簡単に行えるわけですが、あえて簡単だとは言いません。
なぜなら、コンテンツやUIフレームワーク、ホスティングサービス（サーバ）に依存するからです
（ボトルネックとなる部分はAstro以外にもあるので）。
その点を除けば、簡単に速いウェブサイトが作れると言えるでしょうか。
Cloudflare Pages
メリット
注目すべきはレスポンス速度で、CloudflareのCDNが優秀であることは言うまでもないでしょう。
Cloudflareが提供するセキュリティの機能も利用可能で、
設定はSaaSで非常に簡単に行えます。
また、無制限の転送量が挙げられます。
SSRについてはVercelのようなサーバーレス関数が用意されています。 これは無制限ではありませんが、1日10万リクエストまでとそれなりの制限があります。
ビルドや高速化の設定もSaaSで簡単に行えます。様々なフレームワークに最適化することも出来ます(AstroやNext.js、Nuxtなど)。 ビルドにかかる時間はフレームワークに依存しますが、キャッシュ機能があるのでさほどストレスは無いと思います。
デメリット
1か月に500デプロイまでの制限があります。 有料プランは決して安く無いため、更新頻度か高いウェブサイトや複数のウェブサイトの運用には向いていないでしょうか・・・。
Stylus
Stylusの特徴はボイラープレートコードが最小限であることです。
CSS
div {
display: flex;
}
div > a {
text-decoration: none;
}
div > a:hover {
text-decoration: underline;
}
SCSS
div {
display: flex;
a {
text-decoration: none;
&:hover {
text-decoration: underline;
}
}
}
SASS
div
display: flex
a
text-decoration: none
&:hover
text-decoration: underline
Stylus
div
display flex
a
text-decoration none
&:hover
text-decoration underline
このように、波括弧やコロン・セミコロンを省略できます。
上の二つのコードもStylusではエラーになりません。
CSSには完全に下位互換があり、SASS/SCSSには一部下位互換があります。
SASS/SCSSほど情報が充実しておらず、機能もSASS/SCSSの方がありますが、Stylusはその構文及び言語仕様に価値があります。
しかし、セミコロン等を記述しなければ正しく構文を理解しなかったり、 importエイリアスに対応していない（対応しない？）などから、 SASS/SCSSからポジションを奪取するほどの強さは感じられません。
ちなみに、PostCSSとStylusは併用することが出来ます。
JSXの<style>であれば、SASS/SCSSなどとファイルごとに使い分けられると思います。
（なので選定の必要がそもそもないと言っても過言ではないかもしれません。）
Porkbun
ドメインを買おうとしたのは2023年の夏頃だったと記憶してますが、
その当時Google DomainsがSquarespaceという全然知らない企業に移行するという話がありました。
そのため、購入先は別の企業からと考えていました。
お名前.comやXserver domain、ムームードメインなど日本の企業は沢山ありますが、
これらは更新費が簡単にチェックできないため非常に面倒です（それも戦略なのでしょうが・・・）。
調べていくと、Cloudflareが安価でドメインを販売しているようでした。
しかし、その当時は.devドメインは販売しておらず、追加も怪しい状況にありました（後日、追加されたようです）。
調査の末、Porkbunという企業を見つけました。
このPorkbunは安価で、更新費を包み隠さず、
当然のごとくWhois代行を無料でつけてくれます。
支払いの手段も多く、Paypalが使えます。
SSLも無料で使えますが、
私はCloudflareで管理しているのでこの恩恵特に受けていませんが、
Cloudflareを使っていない人にとっては助けになるかもしれません。
Svelte
Svelteもボイラープレートコードが少なく、 Reactなどと比べて学習コストが低いです（日本語のドキュメントとチュートリアルがあります）。 ただし、Reactを使い続けてきたエンジニアにとっては 言語仕様の点で異なる点があるので少しとっつきにくい部分はあります。
パフォーマンスが高く、アニメーションの機能を標準で搭載していたり、便利で高速というのがSvelteのメリットです。 エコシステム（ライブラリやパッケージ）がReactなどより少ないこと、知見が少ないなどがデメリットでしょうか。 大規模なウェブサイト・Webアプリケーションの開発にはReactの方が分があります。 個人的にSvelteはAstroと非常に相性が良いと思っています（ランタイムがほぼなく、バンドルサイズが小さいため）。
ちなみにPagefindのDefaultUIや、 YouTube ReVancedのウェブサイトはSvelteで作られています。
Qwik
まず、レンダリングの手法として
- クライアントでレンダリングするCSR
- クライアントの情報をもとにサーバーでレンダリングするSSR
- ビルド時にレンダリングを終わらせるSSG
- SSRを毎回行わない賢いSSR、ISR
- SSGのうち、必要な部分のみSSRにするIslands Architecture
このうちSSRとSSG、Islands ArchitectureではHydrationという処理が行われます。
動的なコンテンツを使用する場合、
JSのダウンロードと有効化（スクリプトの解析・実行）をして、
静的なコンテンツに落とし込む必要があります。
完全な表示にはHydrationがボトルネックとなるわけです（Web上のランタイムみたいな感じ）。
Islands Architectureではそれを部分的に行い、最小限のHydrationを実現していますが、範囲が限定的になってしまうのは言うまでもないでしょう。
何かに例えるならば、乾いたHTML(砂漠)にHydration(水分補給)をして、
ウェブサイトが動き出す（緑化して動物などが生き生きとしている）ようなイメージでしょうか（ゴミみたいな例えですみません）。
そこで提唱されたのがResumableという新しい概念であり、 これはイベントが発生（発火）してからJSのダウンロードや実行を行います。 プリフェッチや非同期的なダウンロードを自動的に設定し、 最適化を行うことで別次元のSSRを実現しているようです。
構文的にはReactに近いです。 Reactからの移行を重点的にサポートしているようで、 Qwik Reactなどがあります。
Qwikの懸念点はその学習コストの高さです。情報量も極めて少なく、 ドキュメントもエコシステムも若干不十分なところがあるのは事実です。 制約が厳しく、初心者向けではありません。自己解決力が強く、 英語に全くアレルギーが無いエンジニアにとっては、 やりがいのあるチャレンジになるかもしれません。
各フレームワークのコードに変換できるmitosisのようなイカれたプロジェクトもあるので、
学習コストがそもそも無くなる場合もありますが、
は知名度も高いとは言い切れず、確立されたフレームワークで無いことも確かです。
BuilderIOが今後どのような動きを見せるのか注目すべきではあります。
開発環境は?
実は実装時に変更したものや、移行したものがあります。
| 移行前 (検討時) | 移行後 (実装時) |
|---|---|
| Tailwind CSS | Stylus |
| Lit | Svelte & Qwik |
| WSL2 | Windows |
| Algolia | Pagefind |
能力的な問題や、仕様的な問題がほとんどです。
現在はWindows 11でVSCodeをエディタとして開発しています。
環境はCargoからfnmをインストールして構築しています。
ソースコードはGitHubで管理し、Cloudflare Pagesにデプロイして公開しています。
ドメインも、Cloudflareのネームサーバを指定してCloudflareのDNSを使って公開しています。
おわりに
7rs/pages
ちなみにこのウェブサイトはオープンソースです。
貢献して頂けるのなら非常に助かりますが、 私にやる気があるかはわかりません。
質の良い答えを返せるかどうかわかりませんが、質問なども受け付けます。
指摘があれば是非お願いします。
本日は以上です。ありがとうございました。