Swiftで静的サイトを作る

UIのランタイムはブラウザ#

SwiftUIがiOSで自然に使えるのは、その抽象化がシステムのUIランタイムへ直接つながっているからだ。

1
iOS:
2
System UI runtime
3
→ SwiftUI Button / VStack / NavigationStack
4
→ Your Swift code
5
Web:
6
Browser runtime (DOM + CSS + JS)
7
→ HTML <button> / <div> / <article>
8
→ CSS grid / flex / selectors
9
→ Your HTML/CSS/JS

SwiftUIのButtonは、アクセシビリティ、フォーカス、アニメーション、入力といったプラットフォームの挙動に結びついている。一方、RaptorやIgniteで宣言したボタンが最終的に生成するものは、

1
<button class="...">Save</button>

とCSSだ。ブラウザは元のSwiftコンポーネントを知らず、受け取ったHTML、CSS、JavaScriptだけを実行する。

宣言的UIが問題なのではない。React、Vue、Astroも宣言的であり、違うのは何を宣言しているか、そしてブラウザ本来のモデルからどれだけ離れているかだ。

SwiftUIはプラットフォームのモデルとよく一致する。ReactはDOMを扱い、AstroはHTMLをコンポーネントの第一級要素として扱う。IgniteとRaptorは、そこからさらに上にSwiftのコンポーネントツリーを置く。簡単なページでは便利だが、デザインの独自性が高くなるほど変換コストが表に出てくる。

コンポーネントDSLが楽ではなくなる地点#

IgniteのようなAPIは、単純なUIなら素早く書ける。

1
Text("Hello")
2
Button("Read More")
3
Grid {
4
  Card { ... }
5
}

Bootstrapによってレイアウト、余白、レスポンシブ対応、基本的な視覚階層が最初から用意される。ドキュメント、ポートフォリオ、一般的なブログなど、組み込みの語彙で表現できるサイトにはよく合う。

ところが、既存のビジュアルテーマを移植しようとすると、次のようなCSSが必要になる。

1
.card::before
2
.sidebar:has(.active)
3
grid-template-columns: minmax(0, 1fr) 18rem
4
position: sticky
5
backdrop-filter
6
mask-image
7
container queries

組み込みコンポーネントで表現できなくなると、Swift側も結局は低レベルなHTMLラッパーへ戻る。

1
Tag("aside") { ... }
2
.class("layout-shell__sidebar")

CSSは別途書かなければならない。ページの半分がSwiftUI風の語彙、残りがHTMLのラッパーになり、抽象化によって減る作業が少なくなってしまう。

もちろん、この方法が扱いやすい範囲は明確にある。

1
Simple sites
2
Docs
3
Portfolios
4
Basic blogs
5
Bootstrap-like layouts

難しくなるのは、AstroやHexoで作られたテーマのように、細かなセレクター、疑似要素、レイアウト規則、ブラウザ固有の挙動に依存する場合だ。これは宣言的UIや各フレームワークの欠陥ではなく、抽象化の適用範囲だと思う。

Sagaは境界を隠さない#

Sagaは別の方針を採る。Swiftが得意な部分をSwiftに任せ、ブラウザ側の関心事はWeb本来の形で残す。

1
Swift:
2
Content model
3
Pipeline
4
Generation logic
5
Type safety
6

7
Web:
8
HTML structure
9
CSS styling
10
JavaScript behavior

テンプレートは次のようになる。

1
article(class: "mx-auto max-w-3xl px-6 py-12") {
2
  h1(class: "text-4xl font-bold tracking-tight") {
3
    item.title
4
  }
5
  div(class: "prose prose-slate dark:prose-invert") {
6
    raw(item.body)
7
  }
8
}

これはSwiftUIをブラウザに再現するものではなく、SwiftでHTMLを生成しているだけだ。役割分担も読み取りやすい。

1
Swift-native:
2
Types, functions, composition
3

4
Web-native:
5
HTML, CSS, browser semantics

今回のようなテーマでは、大きなUI抽象化を追加することより、この直接性のほうが役に立つ。

Tailwindを組み合わせると扱いやすい#

Tailwindを使わないSagaのテンプレートは、名前付きクラスを使う従来のHTMLに近い。

1
article(class: "post-card") {
2
  h2(class: "post-card__title") {
3
    item.title
4
  }
5
}

Tailwindを使えば、レイアウトとスタイルをHTML生成箇所のすぐそばに置ける。

1
article(class: "group rounded-3xl border border-slate-200 bg-white p-6 shadow-sm transition hover:-translate-y-1 hover:shadow-lg") {
2
  h2(class: "text-2xl font-semibold tracking-tight") {
3
    a(href: post.url) {
4
      post.title
5
    }
6
  }
7
}

CSSの概念を一つずつSwiftのmodifier APIへ置き換える必要がない。Tailwindはutility classで表現したCSSなので、ブラウザ側のモデルも見失わずに済む。

RaptorとIgniteは向いている仕事が違う#

Raptorは一般的なSSGより広い範囲を扱おうとしており、次のようなサイトモデルを持つ。

1
Site
2
Page
3
PostPage
4
CategoryPage
5
Layout
6
Theme
7
Style
8
PostWidget

さらにVaporと統合してサーバーサイドレンダリングもできる。Swift中心のコンテンツプラットフォーム、静的・動的ページの混在するサイト、バックエンド統合が必要なプロジェクトなら面白い選択肢になる。

ただし、このサイトモデルだけで複雑なフロントエンドを簡単に表現できるわけではない。UIとスタイルシステムの範囲を超えると、実装は再び、

1
Tag + Div + Class + CSS

に戻る。この段階では、上位の抽象化がコンテンツ設計やサーバー統合など別の問題を解決しているかどうかを確認したい。フロントエンドの作業量は、もう減っていないからだ。

Igniteはもっと現実的な組み合わせを選んでいる。

1
Swift API + Bootstrap

小規模サイト、ポートフォリオ、ドキュメントを短時間で作る用途には向いている。一方、独自のビジュアルを追求すると、Bootstrapの構造や見た目を隠すのが次第に難しくなる。

複雑なテーマなら今もAstroを選ぶ#

Swiftを使うこと自体が要件でなければ、今回のような複雑なビジュアルテーマではAstroが最も安定した選択だと思う。

• HTML、CSS、JavaScriptを第一級の要素として扱える
• コンポーネントがブラウザのプリミティブに近い
• Tailwindを素直に統合できる
• Content Collectionsでコンテンツを構造化できる
• エコシステムが成熟している

SwiftでWebサイトを作れないという意味ではない。Swiftによる抽象化のコストに対して、プロジェクトが必要とする価値を得られるかどうかが重要になる。

今回比べた二つの方向性は、次のように整理できる。

1
Swift expresses UI
2
→ translated into HTML/CSS

1
Swift handles logic and structure
2
HTML/CSS/JS express the UI

1
Not using Swift: Astro + Tailwind
2
Using Swift seriously: Saga + Tailwind
3
Quick Swift site: Ignite
4
Exploring Swift Web frameworks: Raptor