The Web Already Has a Native Runtime#

SwiftUI works on iOS because it maps directly to a system UI runtime.

You can think of it like this:

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

A SwiftUI Button is not a simulation — it connects directly to platform behaviors: accessibility, focus, animation, input.

But a Button in Raptor or Ignite ultimately becomes:

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

plus CSS.

The browser has no idea what a Swift Button is. It only understands HTML, CSS, and JS.

So the issue is not whether declarative UI is good — React, Vue, and Astro are all declarative.

The difference is what you are declaring.

What Are You Actually Declaring?#

Let’s compare:

This table doesn’t say which is better — it shows how closely your mental model matches what the browser actually runs.

SwiftUI works because the abstraction matches the platform.

React works because it still models the DOM.

Astro works because it embraces HTML as a first-class citizen.

Raptor and Ignite, however, try to move the abstraction upward — into a Swift component tree.

That works beautifully for simple pages.

But when the UI becomes complex, friction appears.

The Sweet Spot — and the Cliff#

Frameworks like Ignite shine when the UI is simple:

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

Bootstrap gives you layout, spacing, responsiveness, and visual hierarchy for free.

But real-world visual themes often require things like:

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

Once you go beyond built-in components, you often fall back to:

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

and then write CSS anyway.

At that point, the abstraction becomes fragmented:

half SwiftUI-style, half HTML wrapper.

The issue isn’t that Raptor or Ignite are flawed.

It’s that their abstraction sweet spot is:

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

When your goal is a highly customized visual theme, especially one originally written in Astro or Hexo, the abstraction starts to break.

Saga: Swift Purism, Not SwiftUI Purism#

Saga takes a very different approach.

Instead of trying to replace Web primitives, it divides responsibilities cleanly:

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

A Saga template might look like:

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
}

This is not SwiftUI.

It does not pretend to be.

It is simply Swift generating HTML — with full respect for Web primitives.

That’s why Saga feels more “native” in both worlds:

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

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

Tailwind Changes the Experience#

Without Tailwind, Saga feels like classic HTML + CSS:

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

With Tailwind:

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
}

Now you’re controlling layout, spacing, and style directly at the HTML level.

No translation needed.

This avoids one of the biggest problems in SwiftUI-style DSLs:

translating CSS concepts into Swift modifiers.

Instead, Tailwind remains CSS — just expressed differently.

Raptor: Ambitious, but Friction-Prone for Complex UI#

Raptor aims higher than a typical SSG.

It defines:

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

It even integrates with Vapor for server-side rendering.

This is powerful — especially for:

• Swift-first content platforms
• Static + dynamic hybrid sites
• Backend integration

But it doesn’t automatically solve front-end expression.

In fact, once UI becomes complex, you often end up writing:

1
Tag + Div + Class + CSS

again.

Which raises a fundamental question:

If complex UI still requires Web-native expression, what value does the abstraction add?

Ignite: Fast, but Opinionated#

Ignite is more pragmatic.

It embraces:

1
Swift API + Bootstrap

This makes it great for:

• quick sites
• portfolios
• documentation

But Bootstrap becomes visible.

If your goal is a highly customized visual identity, the built-in structure can become limiting.

Astro: Still the Most Stable Choice#

If we ignore Swift entirely and ask:

What is the most stable tool for complex visual static sites?

The answer is still Astro.

Because:

• HTML/CSS/JS are first-class
• Components are native to the platform
• Tailwind integration is smooth
• Content Collections provide structure
• Ecosystem is mature

Astro doesn’t fight the Web.

It grows from it.

The Real Question#

This entire exploration leads to a clearer conclusion:

The real question is not “Can Swift build websites?”

It is “Where should Swift be used?”

Final Perspective#

There are two fundamentally different philosophies:

1
Swift expresses UI
2
→ translated into HTML/CSS

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

Final Takeaway#

Swift should not compete with HTML/CSS/JS.

It should complement them.

When Swift tries to replace the UI layer, abstraction costs rise quickly.

When Swift focuses on modeling and generation, its strengths — type safety, composition, and tooling — shine.

TL;DR#

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