Presenting Swiflow, a frontend stack for the web in Swift → Wasm

Community Showcase
1

Does the web need a Swift frontend stack? I don't know, but here's my take on what could be something for me to develop web apps in the future.
(Swiflow is a solo project, built and maintained by me as a hands-on exploration of Swift on the web)
Swiflow is not a UI library; it's a batteries-included frontend stack for single-page apps, written in Swift 6 and compiled to WebAssembly; A virtual-DOM machine in Swift. The bet it tests: WebAssembly moves the work from runtime to compile time, and that buys ergonomics that are structurally hard to get in JS. (The longer argument →)

Repo: https://github.com/zzal/swiflow (Apache 2.0)

  • Reactivity — @Component / @State; @ReducerState for wizard/queue-style client state (pure reducers, effects at the call site); environment, refs, .task effects.
  • SwiflowUI — token-driven components (forms, overlays, virtualized DataTable, coalescing toasts). Components read --sw-* tokens and never branch on dark mode or reduced motion — token layers do. swiflow theme generates WCAG-validated palettes from a brand color at build time.
  • SwiflowQuery — server-state caching: SWR, dedup, optimistic updates with generation-guarded rollback, invalidation, retry/backoff. The hairy interleavings are fuzz-tested plus gated deterministic races.
  • Router / Store / Fetcher — hash & history routing, IndexedDB persistence, typed JSON-over-fetch.
  • Real CSS — the #css macro validates actual CSS at compile time and scopes it per component.
  • The CLI — swiflow init scaffolds a working app; swiflow dev hot-reloads while preserving your @State (edit a color five levels deep in a wizard, stay on step five); swiflow doctor checks your toolchain.

Try it

Requires Swift 6.3.2 + the WebAssembly SDK (two commands, see the README). Then:

# Install the swiflow CLI (prebuilt: macOS arm64 / Linux x86_64)
sh -c "$(curl -fsSL https://raw.githubusercontent.com/zzal/swiflow/main/install.sh)"

swiflow doctor              # checks your toolchain

swiflow init my-app         # will auto-select the HelloWorld template
cd my-app && swiflow dev    # → http://localhost:3000

This is the first version I'm comfortable asking other people to try. If your reaction is "this shouldn't exist, and here's why," I want that review

6 Likes
2

Curious to try this with SwiftXState and WebGPU stuff :D Gonna download and try tomorrow

3

Out of curiosity, I tried incorporating SwiftXState into a Swiflow project.

Good news first: SwiftXState works in Swiflow today, no changes needed on either side.
The caveat is bundle size, measured on optimized release builds:

  • Swiflow starter app: 5.4 MB (1.9 MB gzipped)
  • With SwiftXState: 47.0 MB (18.5 MB gzipped)

Using SwiftXState added ~7 KB — the +41.6 MB comes entirely from linking it, because its core imports Foundation, which on wasm drags in swift-foundation + ICU data. Nothing Swiflow can fix downstream; it's the Foundation-on-wasm tax.

So: great for internal tools and prototypes today; not something I can recommend for public-facing sites until the weight comes down.

4

How does Swiflow compare to existing libraries, such as ElementaryUI?

5

The main differences:

  • ElementaryUI is SwiftUI-inspired (view modifiers). Swiflow is HTML-first — you write div, button, real attributes, scoped CSS modules — so what you write maps 1:1 to the DOM you get. Although you can create reusable Component (React inspired)

  • Bundle size. ElementaryUI supports Embedded Swift, which gets bundles down to kilobytes. Swiflow uses full Swift — a starter app is ~5 MB wasm (~2 MB over the wire) — trading size for the whole language: actors, macros, the full stdlib, and any SwiftPM dependency that compiles for wasm.

  • Swiflow is a broader web app dev solution. Virtual dom with state-preserving HMR, data fetching with caching/mutations (à la Tanstack Query), a page router, a persisted store, a themed accessible UI component library, a form controller, a testing library, and browser devtools all ship in the box. ElementaryUI is more focused on the core view layer.

6

Thanks for the feedback. Check out tag 2.0.0-alpha.7, I've removed Foundation as a dependency from the core target SwiftXState (now we use a custom JSON parser instead of Foundation's). I'll also migrate the Inspect target to Foundation-free shortly, in case you want the JSON output and inspection capabilities.

This brought down the size of the SwiftXState.swiftmodule release build to 1,988,073 bytes (~2MB... 45MB less than when it had Foundation... wow).

2.0.0 is also a really major improvement. It adds a SwiftUI-like declarative state machine DSL, which you can see the DSL in use in the repo examples or in SwiftBuild app (GUI for building the Swift compiler): GitHub - gistya/swift-repo-gui: SwiftUI GUI and mod tracker soundtrack for building the Swift programming language · GitHub

7

Both actors and macros are available in the Embedded Swift mode.

1 Like