How large are the pages?

A blog post is about 14 KB compressed (6.6 KB HTML, 5.4 KB CSS, 1.8 KB JavaScript), and an app page is about 29 KB before screenshots. Pages only receive the CSS and scripts of the components they show.

How is the content managed?

Each app is a Markdown file with typed frontmatter validated at compile time by Swift macros. The build also fetches ratings, prices, and reviews from the App Store, and `swift run website check` verifies facts the compiler can't.

Does it support dark mode and accessibility features?

Yes. Colors are semantic with light and dark values, text/link colors strengthen when the system requests more contrast, and hover effects are gated behind typed media queries like pointer type and reduced-motion settings.

Is there a cost to use it?

The page does not discuss pricing; it is a personal website whose source code is open.

This Website Is Now Made in Swift — A SwiftUI-style website framework, entirely in Swift

sindresorhus.com is the personal website of developer Sindre Sorhus, rebuilt entirely in Swift. The site serves plain HTML, CSS, and a little JavaScript to the browser, but every page, component, and style is written in Swift using a SwiftUI-like component model (built on the Elementary HTML library plus the author's own small framework for styles, routes, and content). The site is also a detailed writeup of how it works: a compiler that catches broken links and typos at build time, styles defined as modifiers, typed CSS variables, Markdown content with typed frontmatter, and a build that pulls live data from the App Store. The source code is open.

Key Features

SwiftUI-like HTML components

Components are Swift structs with a `body` property, built on the Elementary HTML library, and composed like SwiftUI views (e.g. `Badge(title: "New", kind: .new)`).

Styles as modifiers with scoped class names

Styles attach to elements like SwiftUI modifiers and compile to hashed class names (e.g. `back-link-1x2y3z4`) derived from the file name, so styles can't leak between elements. Shared looks are enum cases that autocomplete, and typos don't compile.

Compile-time safety for links and routes

Pages are static members (`.apps`, `.root`) so links autocomplete and nonexistent pages fail to compile. After the build, every link and ID in the generated HTML is verified.

Typed CSS custom properties

CSS variables are typed (e.g. `StyleVariable<Color>`), so assigning a length doesn't compile; `RegisteredProperty` emits the `@property` rule so the browser can animate values.

Typed responsive and accessibility styles

Breakpoints and media queries are typed and combinable with `&&` (e.g. hover effects only applied for fine pointers with motion allowed). Colors are semantic with light/dark values and stronger contrast when the system requests it.

Content as typed Markdown data

Each of the 60+ apps is a Markdown file with typed frontmatter validated by Swift macros (`@Frontmatter`, `@NonEmpty`, `@CalendarDay`) that reject empty values and invalid dates at compile time, with file-and-line errors and "Did you mean" suggestions.

App Store data and checks

The build pulls ratings, prices, and reviews from the App Store, and `swift run website check` catches issues the compiler can't, such as a page claiming a different macOS requirement than the App Store lists.

Small, framework-free output

A blog post is about 14 KB compressed (6.6 KB HTML, 5.4 KB CSS, 1.8 KB JavaScript); pages only load their own components' CSS and scripts, with no web fonts, lazy-loaded below-fold images, background prefetch on link hover, no JavaScript framework, and no bundler.

How It Works

Write components in Swift

Each component is a Swift struct conforming to `HTML` with a `body`, combining markup, styles (as modifiers), and small inline scripts for behavior in one place.

Build with the compiler as the check

Renaming a page breaks compilation of every link to it; the build also runs tests (a few hundred) verifying things types can't catch, such as every class having a CSS rule. Warnings fail the build.

Serve and iterate locally

`swift run website serve` reloads the page on save during development; the final output is static HTML and CSS that any browser renders.

Pros & Cons

Pros

Compiler catches broken links, invalid routes, misspelled keys, and style typos before visitors see them
Very small page weights (~14 KB compressed for a blog post) with no web fonts, no framework, and no bundler
Component-local CSS and JavaScript that disappear with the component when deleted, avoiding selector sprawl
Modern CSS output (cascade layers, light-dark(), relative colors, scroll-driven animations, container units) with per-page style scoping
Strong accessibility support: typed media queries, semantic colors with dark mode and system contrast support

Who It's For

Best for

Swift developers building personal sites or portfolios who want to stay in one language
Projects that value compile-time guarantees (links, types, content validation) over runtime debugging
Sites where minimal page weight and clean, scoped CSS matter

Not ideal for

Teams that need a mainstream, hire-for web stack (JavaScript frameworks, Tailwind, preprocessors — explicitly not used here)
Highly dynamic, client-heavy applications that need a full frontend framework
Developers looking for a turnkey static site generator with plugins and community themes; this is one person's bespoke setup

Use Cases

Personal websites and portfolios where content correctness (links, app metadata, App Store data) matters

Static sites where compile-time verification of links, routes, and styles is preferred over browser-discovered errors

Swift developers who want to build websites in the same language and mental model as their apps

FAQ

What is this?

Sindre Sorhus's personal website, rebuilt entirely in Swift. Every page, component, and style is written in Swift; the browser receives plain HTML and CSS with a little JavaScript.

Is the source code available?

Yes. The article states that the source code is open.

Do I need to know SwiftUI to understand it?

The site is deliberately modeled on SwiftUI — components are structs with a `body`, styles are modifiers, and links work like SwiftUI's `Link` — so familiarity with SwiftUI makes the code familiar, though the HTML itself comes from the Elementary library.

What frameworks or bundlers does it use?

None on the client side: there is no JavaScript framework and no bundler. The HTML comes from Elementary, with the author's own small Swift framework for styles, routes, and content on top.

This Website Is Now Made in Swift