Main page

新しいウェブサイトを作る

日本語

どうして作ったか

自身のウェブサイトを作りたいと前々から思っていて、 苦手なフロントエンドを克服することを目標に当ウェブサイトを開発・運営しています。

ホスティング・技術選定

経験としてはNuxtGitHub Pagesを少しだけ触ったことがあります。 今回は界隈の情勢将来性も含めNext.jsVercelでウェブサイトを作るつもりでした。
しかし、AstroCloudflare Pagesを知り、 それらでウェブサイトを作ることにしました。
(一応、74のウェブサイトNext.jsGitHub Pagesで開発されていますが、 当ウェブサイトよりは開発が活発ではありません。)

メタフレームワーク(フロントエンドフレームワーク) では、 Next.jsNuxtSvelteKitRemixなどが挙げられ、
SSGではGatsbyHugoなどが挙げられますが、 カスタマイズ性とパフォーマンスの点においては、Astroはずば抜けています。

静的ホスティングNetlifyVercelが挙げられますが、 無料プランにおいてはCloudflare Pagesが抜きん出ているでしょうか。

選定の基準としては、
パフォーマンス(ネットワークの速度) >= メンテナンスの状態 >= 使いやすさの順で評価しています。

Astro

全ては説明しきれませんが、いくつかAstroの素晴らしい点をご紹介します。

インテグレーション

package.jsonに追加されるので、Astro専用のパッケージという立ち位置です。
ReactVueなどのJSライブラリや、 TailwindCSSなどのCSSフレームワークに加えて、 SSRアダプターや便利なインテグレーションが多くあります。

pnpm astro add react
pnpm astro add react tailwind partytown

1コマンドでインストールから設定まで自動で行ってくれます。

pnpm dlx @astrojs/upgrade

1コマンドでアップグレード(アップデート)も一括で行ってくれます。

Astro Docs - インテグレーションを追加する
Astro - Integrations

高速

パフォーマンスを重視して開発されているので、 JavaScriptのコードが全てHTMLとCSSに変換されるので、 (出来上がった形としてクライアントに送信される)とにかく速いです。 しかし、そんなことをすれば動的なコンテンツは動かなくなります。 その対応策としてクライアントディレクティブがあります。 これを使えば一部(コンポーネント)のみがJavaScriptで制御されることになります。

デフォルトで高速

この一部がAstroコンポーネントになるわけですが、 ReactVueなどで作ったコンポーネントも呼び出せ、これらのUIフレームワークを混合的に使えます。 もちろん、完全に静的なコンポーネントを作ることも可能で、その場合は通常通り変換が行われます。

この高速化に複雑な設定は必要ありません。 もっと多くのことをしようとすれば複雑にはなりますが、これについても言及されています。
単純なJSXのみで記述することも出来るし(UIフレームワークなしで)、 必要ならば、より踏み込んだ機能(新しい機能やAPI、UIフレームワークなど)にも手を出せる。

Astroを選ぶ理由 - 簡単に使える

ドキュメント

公式ドキュメントが日本語に対応しています。 日本語化が進んでいない部分がありますが、基本的な機能や技術については書かれています。 チュートリアルはブログの作成が日本語化されています。

日本語の記事もそれなりに書かれていますが、技術に偏りがあるのは事実です。
より多くのことをしたいなら、英語の記事を読む必要はあります。

所感

特定のJSライブラリに依存しないので、移行について考える必要が少なくなりますし、 技術や仕様的に不可能だったことが出来るようになる可能性もあります。

学習コストは低いですが、ドキュメントの一部は英語であったり、 新しい機能について日本語の記事はもちろん、英語の記事もほとんどないことがあります。

高速化は簡単に行えるわけですが、あえて簡単だとは言いません。
なぜなら、コンテンツやUIフレームワーク、ホスティングサービス(サーバ)に依存するからです (ボトルネックとなる部分はAstro以外にもあるので)。
その点を除けば、簡単に速いウェブサイトが作れると言えるでしょうか。

Cloudflare Pages

メリット

注目すべきはレスポンス速度で、CloudflareのCDNが優秀であることは言うまでもないでしょう。 Cloudflareが提供するセキュリティの機能も利用可能で、 設定はSaaSで非常に簡単に行えます。
また、無制限の転送量が挙げられます。

SSRについてはVercelのようなサーバーレス関数が用意されています。 これは無制限ではありませんが、1日10万リクエストまでとそれなりの制限があります。

ビルドや高速化の設定もSaaSで簡単に行えます。様々なフレームワークに最適化することも出来ます(AstroNext.jsNuxtなど)。 ビルドにかかる時間はフレームワークに依存しますが、キャッシュ機能があるのでさほどストレスは無いと思います。

デメリット

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からポジションを奪取するほどの強さは感じられません。

ちなみに、PostCSSStylusは併用することが出来ます。
JSXの<style>であれば、SASS/SCSSなどとファイルごとに使い分けられると思います。 (なので選定の必要がそもそもないと言っても過言ではないかもしれません。)

Porkbun

ドメインを買おうとしたのは2023年の夏頃だったと記憶してますが、 その当時Google DomainsSquarespaceという全然知らない企業に移行するという話がありました。 そのため、購入先は別の企業からと考えていました。
お名前.comXserver domainムームードメインなど日本の企業は沢山ありますが、 これらは更新費が簡単にチェックできないため非常に面倒です(それも戦略なのでしょうが・・・)。

調べていくと、Cloudflare安価でドメインを販売しているようでした。 しかし、その当時は.devドメインは販売しておらず、追加も怪しい状況にありました(後日、追加されたようです)。
調査の末、Porkbunという企業を見つけました。 このPorkbunは安価で、更新費を包み隠さず、 当然のごとくWhois代行を無料でつけてくれます。 支払いの手段も多く、Paypalが使えます。
SSLも無料で使えますが、 私はCloudflareで管理しているのでこの恩恵特に受けていませんが、 Cloudflareを使っていない人にとっては助けになるかもしれません。

Svelte

Svelteボイラープレートコードが少なく、 Reactなどと比べて学習コストが低いです(日本語のドキュメントとチュートリアルがあります)。 ただし、Reactを使い続けてきたエンジニアにとっては 言語仕様の点で異なる点があるので少しとっつきにくい部分はあります。

パフォーマンスが高く、アニメーションの機能を標準で搭載していたり、便利で高速というのがSvelteのメリットです。 エコシステム(ライブラリやパッケージ)がReactなどより少ないこと、知見が少ないなどがデメリットでしょうか。 大規模なウェブサイト・Webアプリケーションの開発にはReactの方が分があります。 個人的にSvelteAstroと非常に相性が良いと思っています(ランタイムがほぼなく、バンドルサイズが小さいため)。

ちなみにPagefindのDefaultUIや、 YouTube ReVancedのウェブサイトSvelteで作られています。

Qwik

まず、レンダリングの手法として

このうちSSRとSSG、Islands ArchitectureではHydrationという処理が行われます。 動的なコンテンツを使用する場合、 JSのダウンロードと有効化(スクリプトの解析・実行)をして、 静的なコンテンツに落とし込む必要があります。 完全な表示にはHydrationがボトルネックとなるわけです(Web上のランタイムみたいな感じ)。
Islands Architectureではそれを部分的に行い、最小限のHydrationを実現していますが、範囲が限定的になってしまうのは言うまでもないでしょう。
何かに例えるならば、乾いたHTML(砂漠)にHydration(水分補給)をして、 ウェブサイトが動き出す(緑化して動物などが生き生きとしているようなイメージでしょうか(ゴミみたいな例えですみません)。

そこで提唱されたのがResumableという新しい概念であり、 これはイベントが発生(発火)してからJSのダウンロードや実行を行います。 プリフェッチや非同期的なダウンロードを自動的に設定し、 最適化を行うことで別次元のSSRを実現しているようです。

構文的にはReactに近いです。 Reactからの移行を重点的にサポートしているようで、 Qwik Reactなどがあります。

Qwikの懸念点はその学習コストの高さです。情報量も極めて少なくドキュメントもエコシステムも若干不十分なところがあるのは事実です。 制約が厳しく、初心者向けではありません。自己解決力が強く、 英語に全くアレルギーが無いエンジニアにとっては、 やりがいのあるチャレンジになるかもしれません。

各フレームワークのコードに変換できるmitosisのようなイカれたプロジェクトもあるので、 学習コストがそもそも無くなる場合もありますが、 は知名度も高いとは言い切れず、確立されたフレームワークで無いことも確かです。
BuilderIOが今後どのような動きを見せるのか注目すべきではあります。

開発環境は?

実は実装時に変更したものや、移行したものがあります。

移行前 (検討時)移行後 (実装時)
Tailwind CSSStylus
LitSvelte & Qwik
WSL2Windows
AlgoliaPagefind

能力的な問題や、仕様的な問題がほとんどです。
現在はWindows 11VSCodeをエディタとして開発しています。 環境はCargoからfnmをインストールして構築しています。
ソースコードはGitHubで管理し、Cloudflare Pagesにデプロイして公開しています。 ドメインも、Cloudflareのネームサーバを指定してCloudflareのDNSを使って公開しています。

おわりに

7rs/pages

ちなみにこのウェブサイトはオープンソースです。
貢献して頂けるのなら非常に助かりますが、 私にやる気があるかはわかりません。
質の良い答えを返せるかどうかわかりませんが、質問なども受け付けます。 指摘があれば是非お願いします。

本日は以上です。ありがとうございました。