Swift for Static Sites

The browser is the UI runtime#

SwiftUI works on iOS because its abstractions connect to a system UI runtime:

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 connected to platform behavior including accessibility, focus, animation, and input. A button declared through Raptor or Ignite eventually becomes:

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

plus CSS. The browser does not know about the Swift component that produced it; it only receives HTML, CSS, and JavaScript.

This is not an argument against declarative UI. React, Vue, and Astro are declarative too. The important difference is the object being declared and how closely it matches the browser’s own model.

SwiftUI maps closely to its platform. React still models the DOM, and Astro treats HTML as a first-class part of the component. Ignite and Raptor move the working model farther upward into a Swift component tree. That can be pleasant for a simple page, but the extra translation becomes visible in a heavily customized theme.

Where the component DSL stops helping#

Ignite-style components are convenient for straightforward UI:

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

With Bootstrap underneath, layout, spacing, responsiveness, and basic visual hierarchy arrive quickly. That is a good fit for documentation, portfolios, basic blogs, and other sites that can stay near the framework’s built-in vocabulary.

A migrated visual theme is usually less cooperative. It may depend on CSS such as:

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 the built-in components no longer express the design, the Swift code falls back to lower-level HTML wrappers:

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

The CSS still has to be written. The page is now split between a SwiftUI-style vocabulary and direct HTML and CSS, so the abstraction no longer removes much work.

The useful range for this approach is still real:

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

The difficulty begins when a theme originally built in Astro or Hexo relies on precise selectors, pseudo-elements, layout rules, and browser-specific behavior. This is a boundary of the abstraction, not a defect in declarative UI or in the frameworks themselves.

Saga keeps the boundary visible#

Saga takes a different route. It uses Swift for the parts where Swift is useful and leaves browser concerns in Web-native forms:

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 template can look like this:

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 Swift generating HTML, not an attempt to reproduce SwiftUI in a browser. The division remains easy to inspect:

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

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

For this kind of project, that directness matters more than having a larger UI abstraction.

Tailwind makes Saga more practical#

Without Tailwind, a Saga template resembles conventional HTML with named CSS classes:

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

With Tailwind, the layout and styling remain next to the generated 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
}

There is no need to translate each CSS concept into a Swift modifier API. Tailwind is still CSS, expressed through utility classes, so the browser-facing model stays recognizable.

Raptor and Ignite fit different jobs#

Raptor is more ambitious than a conventional static site generator. It defines a broad site model:

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

It also integrates with Vapor for server-side rendering. That makes it interesting for Swift-first content platforms, static and dynamic hybrid sites, and projects that need backend integration.

The site model does not automatically make a complex front end easier to express, however. When the theme exceeds its UI and style system, the implementation returns to:

1
Tag + Div + Class + CSS

At that point I would want the higher-level model to solve a separate problem—content architecture or server integration, for example—because it is no longer reducing the front-end work.

Ignite makes a more pragmatic trade:

1
Swift API + Bootstrap

It is fast for a small site, portfolio, or documentation project. The trade-off is that Bootstrap’s structure and visual assumptions become harder to hide when the site needs a distinctive theme.

Why I would still use Astro for the complex theme#

If Swift is not itself a project requirement, Astro remains the safer choice for this particular job:

• HTML, CSS, and JavaScript are first-class;
• its components stay close to browser primitives;
• Tailwind integration is straightforward;
• Content Collections provide structure;
• the ecosystem is mature.

That does not make Swift incapable of building websites. It means the cost of the Swift abstraction has to buy something the project needs.

The two Swift approaches I compared can be summarized as:

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