Raptorでぶつかったジレンマ

最初はうまくいった#

Raptorは単にMarkdownからHTMLを生成するだけではない。ページ、レイアウト、テーマ、スタイル、コンポーネントをSwift中心で組み立てるモデルを提供している。通常なら次のように書く部分を、

1
<article class="post-card">
2
  <h2>Title</h2>
3
</article>

Raptorではこう書ける。

1
VStack {
2
    Text(post.title)
3
}
4
.style(PostCardStyle())

型安全で、部品を組み合わせやすく、実装言語をSwiftに揃えられる。開発体験もSwiftUIに近い。SwiftUIがAppleプラットフォームにもたらした書きやすさを、Webにも持ち込めそうに見える。

単純なページなら、その期待どおりに動く。

1
Text("Hello")
2
Button("Read more")

ランディングページ、ドキュメントサイト、基本的なブログは素早く作れる。UIの大半が次の要素に収まるなら、

1
Text + Button + Grid + Card

Raptorの抽象化は簡潔で使いやすい。

独自テーマで境界が見えた#

困ったのは特殊なブラウザ機能ではなく、ブログテーマではよくある細部だった。

1
.meta {
2
  display: flex;
3
  justify-content: space-between;
4
}
5
.meta time {
6
  float: right;
7
}

1
HStack {
2
    categories
3
    Spacer().axis(.horizontal)
4
    time
5
}
6
.style(Property.width(.percent(100)))

1
.recent-info::after {
2
  content: '';
3
  width: 13%;
4
  height: 5px;
5
  background: var(--accent);
6
  position: relative;
7
  bottom: -6px;
8
}

1
RecentInfoAccentBar()

1
.card:hover .read-more {
2
  background-color: var(--bg-hover);
3
}

1
.read-more {
2
  margin-top: -21px;
3
}

1
.style(Property.marginTop(.px(-21)))

1
They think in Swift,
2
but debug in CSS.
3

4
They write components,
5
but fight layout at the DOM level.
6

7
They define styles,
8
but still rely on raw CSS properties.

一つのテーマに二つの考え方#

カードの構造自体は、Swiftのコンポーネントとしてきれいに書ける。

1
PostListItem {
2
    PostMeta(...)
3
    PostTitle(...)
4
    PostExcerpt(...)
5
    PostReadMore(...)
6
}

共通のスタイルもまとめられる。

1
.style(PostCardStyle())

しかし見た目を詰めていくと、指定は少しずつ増えていった。

1
.style(Property.marginTop(.px(12)))
2
.style(Property.paddingLeft(.px(8)))
3
.style(Property.fontSize(.px(14)))

生成後のページが動くのはHTML、CSS、JavaScriptの上なので、最終的な正解はブラウザの挙動で決まる。実際の作業は次のように分かれた。

1
Structure → Swift
2
Styling → CSS concepts
3
Layout debugging → Browser DevTools

感覚としてはこうなる。

1
Half SwiftUI
2
Half traditional Web

複雑さがなくなったわけではなく、場所が移っただけだ。Swiftでコンポーネントを書き、生成されたDOMを確認し、CSSの知識でレイアウトを直していた。

Sagaは境界を隠さない#

Sagaは別の方向を選んでいる。Swiftで構造を組み立てながら、生成されるHTMLとclassもコードからすぐ読み取れる。

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") {
6
    raw(item.body)
7
  }
8
}

役割分担はそのまま見えている。

1
Swift → structure + composition
2
HTML → structure
3
CSS → styling

書いたコードとブラウザで調べるページの間にある翻訳が少ない。見た目を細かく作り込むサイトでは、Webの上にSwiftUI風のレイヤーを置くより、こちらのほうが理解しやすかった。

Raptorを使う範囲#

SwiftでWeb UIを表現すること自体はできる。考えるべきなのは、レンダリング環境からどこまで離れると抽象化の利点が消えるかだ。

汎用的なUIでは、

1
Abstraction helps

高度にカスタマイズしたUIでは、

1
Abstraction fights the platform

Raptorが強いのは前者だ。一般的なコンポーネントで構成されたページなら、型安全と合成のしやすさがそのまま利点になる。後者では、セレクター、疑似要素、小さなレイアウト調整が重要になるほど、抽象化が扱いにくくなる。

スタック全体には、やはり二つの層がある。

1
Rendering layer → HTML / CSS / JS
2
Authoring layer → Swift / React / Astro

ReactやAstroはレンダリング層との距離が比較的近い。Raptorは意図的にそこから離れることでSwiftUIらしい体験を作っているが、その距離が今回のテーマ制作ではずれとして現れた。

このテーマを作ったあと、自分の中では次の境界に落ち着いた。

1
Swift for logic → great
2
Swift for UI abstraction → situational
3
HTML/CSS/JS → still the source of truth

構造が単純で、汎用コンポーネントが中心のサイトなら、今でもRaptorを選べる。視覚的な細部が多いテーマなら、Sagaのような方法でブラウザ本来のUIモデルを見えるままにしておきたい。