Introduction#

In my previous post, I explored a simple but fundamental question:

Where should Swift live in the Web stack?

After comparing tools like Astro, Saga, Toucan, Publish, Ignite, and Raptor, I came to a preliminary conclusion:

Swift is best suited for modeling content and generation logic,

while HTML, CSS, and JavaScript remain the native layer of UI expression.

However, after actually building a site with Raptor — not just reading docs, but implementing a real theme — I ran into something more concrete.

Not a bug. Not a limitation.

A dilemma.

What Raptor Is Trying to Do#

Raptor is not just a static site generator.

It defines a Swift-first model of the Web:

• Pages
• Layouts
• Themes
• Styles
• Components

Instead of writing:

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

You write:

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

The promise is appealing:

• Type safety
• Composability
• A unified language (Swift)
• A SwiftUI-like developer experience

In theory, this brings the same productivity gains SwiftUI brought to iOS.

The Sweet Spot#

For simple pages, this works extremely well.

You can write:

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

And quickly build:

• landing pages
• documentation sites
• simple blogs

The abstraction feels clean, expressive, and productive.

If your UI fits into:

1
Text + Button + Grid + Card

Raptor feels great.

Where It Starts to Break#

But real-world UI rarely stays simple.

Especially if your goal is to build a custom visual theme.

Let’s take a very common pattern from blog themes:

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
}

Example 4: Negative margins and layout hacks#

In CSS:

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

In Raptor:

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

At this point, you are not escaping CSS.

You are translating it.

The Core Dilemma#

This leads to the central issue:

Raptor tries to replace Web UI with Swift abstractions,

but it still runs on a platform that only understands HTML, CSS, and JavaScript.

So developers end up in a strange position:

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.

The abstraction doesn’t remove complexity.

It relocates it.

The Practical Reality#

In practice, building a real theme feels like this:

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)))

The Fragmentation Problem#

You end up with a split mental model:

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

This creates a workflow that feels:

1
Half SwiftUI
2
Half traditional Web

Not fully one or the other.

Comparison: Saga#

This is where Raptor differs sharply from Saga.

Saga does not try to replace Web UI.

It embraces it.

Example:

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
}

Here:

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

No translation layer.

No abstraction mismatch.

Why This Matters#

The problem is not whether Swift can express UI.

It can.

The problem is:

Should it?

For simple UI:

1
Abstraction helps

For complex UI:

1
Abstraction fights the platform

A Key Insight#

After building a real site, the conclusion becomes clearer:

Raptor’s abstraction is strongest where UI is generic,

and weakest where UI is highly customized.

Which is exactly where you need control the most.

A More General Perspective#

This is not just about Raptor.

It’s about layers.

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

React and Astro work well because they remain close to the rendering layer.

Raptor moves further away.

That distance is both its strength and its weakness.

Conclusion#

Raptor is an ambitious attempt to bring SwiftUI-style thinking to the Web.

But the Web already has its own native UI system.

The dilemma is not about capability.

It’s about boundaries.

When Swift tries to replace Web UI,

the abstraction cost grows quickly.

When Swift complements Web UI,

its strengths actually shine.

In the end:

The Web tends to win.

Final Takeaway#

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

TL;DR#

• Raptor shines for simple, structured UI
• It struggles with complex, highly customized layouts
• CSS concepts inevitably leak through
• Saga-style approaches feel more stable for visual-heavy sites
• The real question is not “Can Swift build UI?” but:

“Where should Swift stop?”